Name	Position
John C. Filderman	Director
Joseph Brian Promo	Director
Stephen C. Propper	Director

Name	Position
James N. Ciriello	President

Name	Position
Merck Sharp & Dohme Corp.	Not Applicable

18.2 How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?

MRH believes that the proposed .MERCK community-based gTLD has the potential to offer a variety of benefits to Internet end-users, such as establishing a trusted source of information and an online marketplace for the millions of end-users searching for related information through Merck’s online resources as well as the resources of the identified community members.

In addition, MRH anticipates that .MERCK gTLD can provide Merck, its qualified subsidiaries and affiliates, Merck foundations and related parties, and approved licensees with short and memorable Internet addresses, as well as provide increased navigation to products, services, advertising campaigns, public interest content, and public awareness initiatives. A .MERCK gTLD can also minimize the cost and need for defensive registrations because domain names within the .MERCK gTLD will only be allocated by MRH to eligible community members.

Also, end-users may benefit from lower incidents of phishing and malware often associated with mistypes of domain names in the .COM space that are owned by cybersquatters since they will be navigating to domain names in the .MERCK gTLD.

18.2.1 What is the goal of your proposed gTLD in terms of areas of specialty, service levels, or reputation?

The primary mission and purpose of the .MERCK gTLD is to provide a trusted, hierarchical, and intuitive online marketplace for Internet users seeking the services of, or information about, Merck community members. As such, the .MERCK gTLD will be reserved for the exclusive use of members of the clearly defined Merck community.

Given that end-users are increasingly demanding access to information related to the Merck family of marks through a variety of channels, which include domain names, MRH believes that the .MERCK gTLD has the potential to provide an innovative, virtual avenue to this content that will deepen and broaden its relationship with these end-users.

The continued success of .MERCK is centered on its role as a more trusted and safer environment. Internet users increasingly find themselves challenged by opportunists and charlatans online who present themselves as legitimate businesses. This is a particular challenge in the healthcare industry, where consumers are entrusting sensitive information – and, ultimately, their heath – to uncertified parties.

These rogue online operators register domain names in a variety of top-level domains that look similar to the names of legitimate members of the healthcare community, who also register second-level names within the same generally-available extension. Consumers are lured into ʺphishingʺ attacks by emails that either promise them unrealistic deals or pose as healthcare providers.

The .MERCK gTLD would allow community members to reach end-users through the newest available medium and to help improve healthcare.

Because of the strict vetting that will occur before a second-level .MERCK domain will be awarded, phishing attacks will be minimized within the .MERCK gTLD. The Merck community, operating through the .MERCK gTLD, could minimize many Internet risks for millions of consumers.

18.2.2 What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?

As a branded gTLD, the primary driving factors of the .MERCK gTLD are differentiation and innovation. The success of the gTLD will not be measured by the number of domain names registered. Instead, it will be measured by the levels of consumer recognition and trust that are placed in the .MERCK gTLD. Using this benchmark, MRH will strive to build consumer recognition and trust that rise to the levels of those found in the .EDU and .GOV gTLDs.

As a leading healthcare company, Merck leverages emerging technologies to deliver healthcare information, products and services internationally. The .MERCK gTLD has the potential to aid this online strategy for Merck and the eligible community members, if potential consumer benefits that ICANN experts have anticipated become a reality.

18.2.3 What goals does your proposed gTLD have in terms of user experience?

MRH believes that the .MERCK gTLD will provide a single, trusted ecosystem experience for the millions of end-users seeking information about Merck’s products and services as well as the defined community members that use the Merck family of marks. In addition to providing end-users with short, memorable, and intuitive domain names, MRH will have best-in-class safeguards to minimize any potential infringing or pirated content within the .MERCK gTLD.

Merck’s continued provision of relevant health and medical information to both providers and patients through dedicated websites illustrates the company’s longstanding commitment to improve healthcare. Websites that are based on the Merck family of marks draw over 4 million visitors per year from the United States and Canada.

MRH will also continue to stay abreast of changes in the new gTLD space following commencement of operations and will adjust its strategy as needed to ensure it is providing the most valuable and relevant experience for end-users.

18.2.4 Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.

Registrations within the community may be made by the following businesses, institutions, or organizations:

(a) Qualified subsidiaries and affiliates
(b) Merck foundations and related parties
(c) Approved licensees

As the operator of the .MERCK gTLD, MRH will take its responsibilities to the community extremely seriously. Due to the nature of the activities that will be conducted using the .MERCK gTLD, it is essential that registrations only be permitted by verified members of the community, namely qualified subsidiaries and affiliates of Merck, Merck foundations and related parties, as well as approved licensees. In addition to validating the eligibility of the registrant, a further requirement will be that all registered domain names comply with appropriate name selection and use measures.

MRH and Merck will incorporate all required ICANN consensus policies and other legal⁄policy requirements imposed on new gTLD applicants into the appropriate subsidiary, affiliate, licensee, and Merck foundation, or other agreements.

18.2.5 Will your proposed gTLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures.

Merck recognizes first hand that this is an evolving area of law in which there is no uniform international standard. As a global healthcare company, Merck respects the privacy of its end-users. The company employs a variety of physical, electronic, contractual, and managerial safeguards to protect personal and confidential information on its websites. Merck will take similar precautions to protect registrant and user data associated with the .MERCK gTLD. Furthermore, given the identified .MERCK community, MRH has a vested interest in ensuring that accurate and current registrant information is readily available in connection with each .MERCK domain name.

MRH will ensure that the operation of the .MERCK gTLD will be consistent with Merck’s Statement of Privacy Principles, available on its website at http:⁄⁄www.merck.com⁄privacy⁄.

In addition, MRH intends to incorporate contractual language in its Registry-Registrar Agreement (RRA) modeled after language which has been included in the template Registry Agreement and which has been successfully utilized by existing ICANN gTLD Registry Operators.

The template Registry Agreement states “Registry Operator shall (i) notify each ICANN-accredited registrar that is a party to the registry-registrar agreement for the TLD of the purposes for which data about any identified or identifiable natural person (“Personal Data”) submitted to Registry Operator by such registrar is collected and used under this Agreement or otherwise and the intended recipients (or categories of recipients) of such Personal Data, and (ii) require such registrar to obtain the consent of each registrant in the TLD for such collection and use of Personal Data. Registry Operator shall take reasonable steps to protect Personal Data collected from such registrar from loss, misuse, unauthorized disclosure, alteration or destruction. Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars.ʺ

18.2.6 Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

Merck has a legacy of liaising with industry counterparts for the promotion of products and industry initiatives. This dedication to relationship management will likely be carried over into Merck’s operation of the .MERCK community.

MRH also plans to carefully review the response from search engines to gTLDs, and the perception of end-users. As the marketplace evolves, MRH will invest in outreach and communication as needed to ensure that its end-users continue to interact with the Merck family of marks’ content, services, and products in a simplified, efficient, and productive manner.

18.3.1 What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)?

MRH has proposed operating rules to limit registration to members of the .MERCK gTLD community and will provide a trusted online environment for end-users.

Therefore, one way in which social costs will be eliminated is that there will be no defensive need for other trademark and brand owners to register second-level domains in the .MERCK gTLD. In addition, the .MERCK gTLD will provide end-users with a trusted source for information, goods, and services related to the Merck family of marks.

18.3.2 What other steps will you take to minimize negative consequences⁄costs imposed upon consumers?

MRH believes that the proposed operation of the .MERCK gTLD as set forth in this application has no known negative consequences or cost implications to end-users. On the contrary, the proposed operation of this registry will likely lead to direct and quantifiable benefits to end-users.

18.3.3 How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?

MRH does not envision multiple applicants for the same second-level domain name, as domain names will only be allocated to the identified .MERCK gTLD community members.

18.3.4 Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).

MRH does not envision any advantageous pricing, introductory discounts, or bulk registration discounts at this time because these marketing⁄commercial initiatives are inconsistent with the mission and purpose of the .MERCK gTLD as a trusted online source identifier for qualified subsidiaries and affiliates of Merck, Merck foundations and related parties, as well as approved licensees.

Moreover, it is the current intention of MRH to provide domain name registrations initially at no cost. However, the company reserves the right to reevaluate this decision and may choose to impose a fee in the future.

18.3.5 Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.

MRH is committed to providing the domain name registration periods set forth in the Registry Agreement. Moreover, it is the current intention of MRH to provide domain name registrations initially at no cost. Therefore, providing contractual commitments in a domain name Registrant Agreement regarding the magnitude of price escalations does not seem relevant or appropriate.

MRH acknowledges that the current template Registry Agreement requires that the Registry Operator “shall offer registrars the option to obtain registration periods for one to ten years at the discretion of the registrar.” However, members of the .MERCK gTLD community, as the sole registrants within the .MERCK gTLD, will only be registering domain names on an annual basis. This is done to better account for costs on an annual basis as well as to provide for more concise financial statements in Question 46 of this application, e.g., no multi-year registration or deferred revenue.

Merck & Co. Inc., parent of Merck Sharp and Dohme Corp., Whitehouse Station, New Jersey, USA (collectively “Merck”), is a Fortune 100 company and one of the largest healthcare companies in the world. Merck has operated under the Merck name and trademark in the United States and Canada since as early as 1920. During this time, Merck has established a family of Merck marks that cover a range of goods and services.The family of subsidiaries, affiliates, foundations, licensees, and related parties that are authorized by Merck, to use the Merck marks in a range of economic and philanthropic activities, collectively act as a community. The gTLD string for which Merck is applying reflects this community: .MERCK. Merck has created a new wholly owned subsidiary, Merck Registry Holdings (“MRH”), to apply for and bring the .MERCK gTLD to market.

The Merck community includes, but is not limited to, the following:

1. Merck Core Businesses: Pharmaceutical, Animal Health, and Consumer Care

2. Philanthropic and Corporate Responsibility Programs, such as: Merck for Mothers, The Merck MECTIZAN Donation Program, Merck Company Foundation, and Merck Helps (The ACT Program; SUPPORT Program; Merck Patient Assistance Program; Merck Vaccine Patient Assistance Program)

3. Medical and Scientific Publications and Websites, such as: The Merck Manual, The Merck Index, MerckResearch.net, Merck Medicus, Merck Academy, The Merck Institute for Science Education (MISE), UNCF⁄Merck Science Initiative, Merck Engage, and Merck Services

The Merck community coalesces around the Merck family of marks and the community of interests that relate to those marks. The Merck community is based on Merck’s widely recognized, registered family of Merck marks, and in the community’s internal union around the values, purposes, and common aims developed through decades of development. The community to be served by the .MERCK gTLD is therefore defined and readily identifiable, with members at all levels sharing interests, aims, and commitments to service.

As a community that exists only by virtue of its authorized use of the Merck family of marks, the use of which is restricted, its members are precisely known. As a result of a history of common economic, educational, and philanthropic activities, at a variety of levels, members of the Merck community have common objectives and operational aims.

The Merck community represents a highly organized network of businesses and organizations. These organizations represent a facet of the Merck community’s response to serving their larger communities and their client base. Merck has also been at the forefront of the use of innovative technologies in its research methods, as well as its development and production of new medications in the healthcare industry. Beyond the business world, the Merck community has pioneered the development and adoption of new services and Internet tools to support stakeholders including government health ministries, healthcare and insurance providers, and patients.

MRH, on behalf of Merck, is taking the lead on behalf of the Merck community to initiate the creation of the .MERCK gTLD. The Merck community has the hallmarks of identification and commonality that set it apart from other Internet users. These hallmarks include:

Membership Identification
Operational Accountability
Common Objectives
Well-established Members

1. Membership Identification
The Merck community is easily defined by its authorized use of the Merck family of marks. A member of the Merck community must be authorized to use one or more marks controlled by Merck.

As a community-based gTLD, the .MERCK gTLD faces very few hurdles or obstacles in readily and speedily identifying its qualified registrants. MRH is capable of readily implementing polices, rules, and technical methods for validating community members.

2. Operational Accountability
A community is also defined by its ability to exclude those who do not meet its requirements. Along with authorized use of a mark comes accountability. A Merck licensee or authorized user continues its use of the mark on the condition of meeting Merck’s requirements. Entities that may no longer be part of the Merck community will lose their rights to be part of the .MERCK gTLD namespace.

The .MERCK registry will implement compliance and eligibility monitoring, domain name revocation procedures, and recurring consultation with its registrant organizations in the Merck community, to ensure that it is able to maintain accountability to the community for its eligibility compliance.

3. Common Objectives
As an almost century-old business and community grouping, Merck is experienced in developing and working to meet common objectives.

The .MERCK gTLD will be at the forefront of the Merck community’s objectives for the Internet, which may be expressed as:

Identification and reduction of risk;
Timely provision of accurate and innovative healthcare-related information;
Development of best practices and standards; and
Advocacy of Internet policies that are in the broad interest of community members and their clients.

4. Well-Established Representative Organizations
The Merck community has an active membership made up of organizations that range over the full panoply of services, including medical research and development, education, policy development and advocacy, member support, business development, and philanthropy.

Merck has a legacy of liaising with industry counterparts for the promotion of products and industry initiatives. This dedication to relationship management will likely be carried over into MRH’s operation of the .MERCK community.

The structure of the Merck community is crucial in identifying eligible registrants and eligible partners who may assist in registrant outreach in their country or region. Merck’s central role in licensing its marks allows it to maintain direct and certain control over identification of its members and partners. The Merck community has a great deal of experience in identifying members. MRH, the applicant for the .MERCK gTLD, is in the best position to identify and manage the requirements of the .MERCK gTLD.

Merck has continued to lead its industry peers in researching and developing new medicines, creating purchasing assistance programs for patients, and offering thought leadership across its industry through a variety of initiatives, organizations, and publications.

Merck features an extensive network of partners and licensees. Merck continues to foster expanding partnerships with other business and non-profit entities and has numerous years of experience with managing and negotiating these relationships.

Programs such as Merck’s “Merck for Mothers” offer leadership on issues such as maternal mortality and family planning. In addition, the Merck Foundation has allocated more than $600 million to educational and non-profit organizations. Since 2008, Merck has ranked among the top three pharmaceutical companies in the Access to Medicine Index (ATMI) and number one among corporate philanthropy donors in the ATMI.

Merck publishes a wide variety of publications on various medical-related topics, which include the Merck Manuals and Merck Medicus. These publications are used as authoritative sources of information by physicians, veterinarians, and patients. Merck remains committed to continuing to offer these vital resources so that the most up-to-date, relevant information is available to healthcare professionals.

I. Relations to Community and its Constituents⁄Groups
The primary mission and purpose of the .MERCK gTLD is to provide a trusted, hierarchical, and intuitive online marketplace for Internet users seeking the services of, or information about, Merck community members. As such, the .MERCK gTLD will be reserved for the exclusive use of members of the clearly defined Merck community. The .MERCK gTLD is not designed for widespread registration by the public. Instead, registrants and registrations will be restricted by guidelines included in 20(e), below. Uniting the recognized members of this regulated community under one gTLD will provide Internet users with a safe and easy way to seek healthcare information and services.

The .MERCK gTLD will be operated by MRH for the benefit of the Merck community. Merck’s century-old tradition of prioritizing research in its development of new medications is exemplified in the company’s investment in 2011 of $7.7 billion to research and development. This significant allocation of funding both helps to ensure a future pipeline of products and shareholder value, and also displays a firm commitment to advancing the industry as a whole through extensive research.

As noted above, programs such as Merck’s “Merck for Mothers” offer leadership on issues such as preventing maternal mortality during birth and family planning. In addition, the Merck Foundation has allocated more than $600 million to educational and non-profit organizations. Since 2008, Merck has ranked among the top three pharmaceutical companies in the ATMI and number one among corporate philanthropy donors in the ATMI.

The Merck Manuals and Merck Medicus offer comprehensive medical reference points for physicians and nurses, in conjunction with the Merck Index, which provides a record of chemical compounds critical for medications.

As previously stated, Merck’s extensive network of partners and licensees is a cornerstone of the company’s strategy, and Merck has numerous years of experience with managing and negotiating these relationships.

All of the above indicate that Merck is fully capable of, and qualified to, manage the .MERCK community space. Merck’s commitment to operating the gTLD is evidenced in both its prior experience as well as in its answers to all of the questions in this application for the .MERCK gTLD.

II. Accountability Mechanisms of the Applicant to the Community
The Internet community and the .MERCK gTLD will exist in a synergistic relationship. A healthy .MERCK gTLD—one in which consumers learn to trust the gTLD as a symbol of legitimate and trustworthy content—will benefit the Merck community members who use a .MERCK second-level domain. Consumer trust, in turn, will drive best-practices by Merck community members. This synergy ensures strong accountability of each party to the other.

I. Intended Registrants in the gTLD
As stated above and in the response to Question 18 of this application, the .MERCK gTLD community will be clearly defined. Registrations within the community may be made by the following for-profit and not-for-profit businesses or organizations:

(a) Qualified subsidiaries and affiliates
(b) Merck foundations and related parties
(c) Approved licensees

II. Intended End-Users of the gTLD
End-users will not only include the registrants of domain names within the gTLD but also potentially millions of consumers who may visit the .MERCK gTLDʹs websites. Once the .MERCK gTLD is established as a trusted gTLD for all matters related to the Merck community, consumers will know and trust websites in the gTLD as being more secure and stable than any other similar, but generic, websites. See the response to Question 18 of this application for more details.

III. Related Activities the Applicant has Carried Out or Intends to Carry Out in Service of this Purpose
MRH is submitting this application on behalf of the Merck community to ensure that the .MERCK gTLD shall serve as a trusted, hierarchical, and intuitive namespace for this community and the consumers that they serve. All registrants within this gTLD will be vetted prior to registration to ensure their identity and their contractual commitment to industry best-practice standards developed by Merck and MRH, before being able to register in the .MERCK namespace (see 20(e), below). In addition, the registry will employ a network of both active and passive safeguards in the operation of the registry to ensure that these registrants continue to abide by the terms and conditions set forth in their registration agreements.

Promotion of the .MERCK gTLD will be conducted on an ongoing basis to ensure acceptance, familiarity, and trust among members of the community. Consumers quickly will become familiar with .MERCK and will see that its use is limited to trusted, regulated organizations. This dedication to relationship management will be carried over into MRH’s operation of the .MERCK gTLD.

IV. Explanation of How the Purpose is of a Lasting Nature
Merck is one of the largest healthcare companies in the world. Merck has been in operation since as early as 1920 and is a Fortune 100 company.

The .MERCK gTLD will ensure that Internet users know that a .MERCK site is one of the few locations on the Internet providing trustworthy and authoritative information about Merckʹs goods and services. A simple search limited to .MERCK second-level registrants will provide the Internet user with results completely culled of the undesirable and unscrupulous. The beauty of the .MERCK gTLD is that it shifts the burden of confirming authenticity from the consumer to the registry, or the registryʹs designated third-party service provider. Registrant and site authenticity ensure value.

Merck’s continued provision of relevant health and medical information to both providers and patients through dedicated websites illustrates the company’s longstanding commitment to improve healthcare. Websites that are based on the Merck family of marks draw over four million visitors per year from the United States and Canada.

As stated in 20(b), above, the continued success of .MERCK is centered on its role as a trusted and safe environment. Internet users increasingly find themselves challenged by opportunists and charlatans online who present themselves as legitimate businesses. This is a particular challenge in the healthcare industry, where consumers are entrusting sensitive information – and, ultimately, their heath – to uncertified parties.

These rogue online operators register domain names in a variety of top-level domains that look similar to the names of legitimate members of the healthcare community, who also register second-level names within the same generally-available extension. Consumers are lured into ʺphishingʺ attacks by emails that either promise them unrealistic deals or pose as healthcare providers.

The proliferation of healthcare-related information on the Internet in the form of home health websites, patient blogs, and social media communities has created a need for companies in the industry to be innovative in their information distribution strategies. Several key industry trends have been observed:

According to Compete.com, online healthcare information networks have seen a ten percent growth thus far in 2012, largely driven by increased traffic to sites such as WebMD.com.

According to a 2011 joint effort from the Pew Internet Project and California Healthcare Foundation:
-One in four Internet users has watched an online video about health.
-One in four Internet users has tracked their weight, diet, exercise routine, or other health indicator online.
-One in four Internet users has consulted online reviews of drugs or medical treatments (but very few post such reviews).

The .MERCK gTLD would allow community members to reach end-users through the newest available medium and to help improve healthcare.

Because of the strict vetting that will occur before a second-level .MERCK domain will be awarded, phishing attacks will be minimized within the .MERCK gTLD. The Merck community, operating through the .MERCK gTLD, could minimize many Internet risks for millions of consumers.

I. Relationship to the Established Name, if any, of the Community
The .MERCK string is a perfect pairing with the community as defined in 20(a). Only qualified subsidiaries and affiliates of Merck, approved licensees, and Merck foundations and related parties will be eligible for inclusion in this community. Internet users familiar with Merck and its offerings will understand the connection between the gTLD and the Merck community. As already established in 20(c), all second-level domain name registrants in the .MERCK space will have been vetted to ensure that they are identifiable members of the community.

II. Relationship to the Identification of Community Members.
Members of the community are identified as Merck licensees, qualified subsidiaries and affiliates, and Merck foundations and related parties. In all cases and in all situations, they identify themselves as part of the Merck community. As such, registrations within the community may be made by the following for-profit and not-for-profit businesses or organizations:

(a) Qualified subsidiaries and affiliates
(b) Merck foundations and related parties
(c) Approved licensees

Merck defines and authorizes community members and thus has a direct stake in ensuring the trustworthiness and reliability of the .MERCK gTLD and its governance. The broad membership of the Merck community is an advantage in the operation of the .MERCK gTLD, providing a range of contact points in the Internet. Meanwhile, Merck is at the apex of this broad community and understands its span and activities. This strong governance protocol carries through to the operation of the .MERCK gTLD.

I. Registrant Eligibility
Registrations within the community may be made by the following businesses, institutions, or organizations:

(a) Qualified subsidiaries and affiliates
(b) Merck foundations and related parties
(c) Approved licensees

As the operator of the .MERCK gTLD, MRH will take its responsibilities to the community extremely seriously. Due to the nature of the activities that will be conducted using the .MERCK gTLD, it is essential that registrations only be permitted by verified members of the community, namely qualified subsidiaries and affiliates of Merck, Merck foundations and related parties, as well as approved licensees. In addition to validating the eligibility of the registrant, a further requirement will be that all registered domain names comply with appropriate name selection and use measures.

To ensure strict compliance with these policies, the .MERCK gTLD will develop and implement a Registrant Eligibility Criteria Process. This process will require registrars qualified to distribute .MERCK domain names to gather materials from proposed registrants that will be used by the registry to authenticate the registrants’ eligibility as part of the community.

Furthermore, MRH will develop and implement a Registrant Eligibility Evaluation Process. This process will require registrars qualified to distribute .MERCK domain names to collect registrant information that will be used by MRH to authenticate that the registrant is a member of the Merck community. These requirements will be hard coded into the .MERCK Registry-Registrar Agreement (RRA).

As part of the registration process of a .MERCK domain name, potential applicants must provide the registrar with the following information:
Registrant Name
Registrant Organization
Registrant Address
Registrant Phone
Registrant Email

Applicants who pass these eligibility tests will then be able to register their applied-for names. These names will then undergo a test to ensure compliance with the .MERCK content and use policy.

Domain Names that pass the pre-check will enter Pending Create status, and the .MERCK Registry Operator will validate each domain name and either approve or reject the create. Any registrant whose domain name fails the pre-check will be notified with reasons. Any registrant that is either denied initial registration of a domain or has their domain name suspended or canceled has the opportunity to appeal such action by MRH through an administrative procedure. In resolving this dispute, the administrative procedure will ensure that MRH has properly applied the terms and conditions of the .MERCK registrant agreement. Additionally, this administrative procedure shall be binding and non-appealable.

MRH will randomly audit all approved registrants and their second-level domains to ensure compliance with all applicable eligibility and use requirements.

II. Name Selection: What Types of Second-Level Names may be Registered in the gTLD.
At the time of filing this application, MRH has not yet finalized the specific name selection criteria. When this criteria is finalize it will be publicly posted on the MRH website.

III. Content Use
MRH has not yet finalized an Acceptable Use Policy (AUP). A draft policy has been included in response to Question 28 of this application, but has not yet been finalized by Merck’s legal team. Such approval and posting of the policy will be done in advance of the launch of the registry.

IV. Enforcement
MRH will enforce the AUP (which is still subject to legal review) during the term of the .MERCK Registry Agreement.
MRH will have complete enforcement rights over registrants’ use of their .MERCK domain names. If a registrant violates the then in effect AUP, the registrant will be in material breach of the Agreement, and along with all other rights and remedies that MRH has under this Agreement with respect to such a breach, MRH reserves the right to revoke, suspend, terminate, cancel, or otherwise modify the registrant’s rights to the domain name.
On a regular basis, MRH will randomly audit domain names registered in the .MERCK gTLD to ensure compliance with all eligibility and use criteria. If a violation is discovered, an investigation will immediately begin to rectify the violation.

If an applicant chooses to appeal, MRH will review the appeal to determine if there are any material changes to the action or activity. MRH will retain the right to assign the dispute to an ombudsman if necessary.

Merck Registry Holdings, Incorporated (“MRH”), a subsidiary of Merck, is keenly aware of the sensitivity of national governments in connection with protecting country and territory identifiers in the DNS. In preparation for answering this question, MRH reviewed relevant background material regarding the protection of geographic names in the DNS including:

-ICANN Board Resolution 01-92 regarding the methodology developed for the reservation and release of country names in the .INFO top-level domain (see http:⁄⁄www.icann.org⁄en⁄minutes⁄minutes-10sep01.htm);
-ICANN’s Proposed Action Plan on .INFO Country Names (see http:⁄⁄www.icann.org⁄en⁄meetings⁄montevideo⁄action-plan-country-names-09oct01.htm);
-“Report of the Second WIPO Internet Domain Name Process – The Recognition and Rights and the Use of Names in the Internet Domain Name System,ʺ Section 6, Geographical Identifiers (see http:⁄⁄www.wipo.int⁄amc⁄en⁄processes⁄process2⁄report⁄html⁄report.html);
-ICANN’s Governmental Advisory Committee (GAC) Principles Regarding New gTLDs, (see https:⁄⁄gacweb.icann.org⁄download⁄attachments⁄1540128⁄gTLD_principles_0.pdf?version=1&modificationDate=1312358178000); and
-ICANN’s Generic Names Supporting Organization Reserved Names Working Group – Final Report (see http:⁄⁄gnso.icann.org⁄issues⁄new-gtlds⁄final-report-rn-wg-23may07.htm).

MRH is committed to initially reserving the country and territory names contained in the internationally-recognized lists described in Article 5 of Specification 5 attached to the New gTLD Applicant Guidebook at the second level and at all other levels within the .MERCK gTLD at which MRH will provide for registrations. Specifically, MRH will reserve:

-The short form (in English) of all country and territory names contained on the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union (see http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU);
-The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
-The list of United Nations member states in six official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.

MRH’s parent company, Merck & Co. Inc., parent of Merck Sharp and Dohme Corp., Whitehouse Station, New Jersey, USA (MSD) (collectively “Merck”), is a leading healthcare company serving the wide-ranging needs of patients and providers around the world, with more than 86,000 employees in upwards of 140 countries. Given this geographic approach to finding localized MSD content, MRH intends to explore the option of providing a hierarchical and intuitive framework for the .MERCK namespace by using geographical identifiers as second-level domain names.
MRH, either directly or through its designated representatives, will monitor efforts by other new gTLD Registry Operators in potentially working with ICANN’s GAC to explore potential processes that could permit the release of initially-reserved country names (including ISO-3166 two characters). Specifically, MRH is interested in exploring Registry Service Evaluation Processes (RSEP) requests that have been filed by other gTLD Registry Operators in releasing reserved domain names.

Q.23 – Registry Services

23.1 Customary Registry Services

As Merck Registry Holdings, Inc.’s selected provider of backend registry services, Verisign provides a comprehensive system and physical security solution that is designed to ensure a TLD is protected from unauthorized disclosure, alteration, insertion, or destruction of registry data. Verisign’s system addresses all areas of security, including information and policies, security procedures, the systems development lifecycle, physical security, system hacks, break-ins, data tampering, and other disruptions to operations. Verisign’s operational environments not only meet the security criteria specified in its customer contractual agreements, thereby preventing unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with applicable standards, but also are subject to multiple independent assessments as detailed in the response to Question 30, Security Policy. Verisign’s physical and system security methodology follows a mature, ongoing lifecycle that was developed and implemented many years before the development of the industry standards with which Verisign currently complies. Please see the response to Question 30, Security Policy, for details of the security features of Verisign’s registry services.

Verisign’s registry services fully comply with relevant standards and best current practice RFCs published by the Internet Engineering Task Force (IETF), including all successor standards, modifications, or additions relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472. Moreover, Verisign’s Shared Registration System (SRS) supports the following IETF Extensible Provisioning Protocol (EPP) specifications, where the Extensible Markup Language (XML) templates and XML schemas are defined in RFC 3915, 5730, 5731, 5732, 5733, and 5734. By strictly adhering to these RFCs, Verisign helps to ensure its registry services do not create a condition that adversely affects the throughput, response time, consistency, or coherence of responses to Internet servers or end systems. Besides its leadership in authoring RFCs for EPP, Domain Name System Security Extensions (DNSSEC), and other DNS services, Verisign has created and contributed to several now well-established IETF standards and is a regular and long-standing participant in key Internet standards forums.

Figure 23 1 summarizes the technical and business components of those registry services, customarily offered by a registry operator (i.e., Verisign), that support this application. These services are currently operational and support both large and small Verisign-managed registries. Customary registry services are provided in the same manner as Verisign provides these services for its existing gTLDs.

Through these established registry services, Verisign has proven its ability to operate a reliable and low-risk registry that supports millions of transactions per day. Verisign is unaware of any potential security or stability concern related to any of these services.

Registry services defined by this application are not intended to be offered in a manner unique to the new generic top-level domain (gTLD) nor are any proposed services unique to this application’s registry.

See Figure 0 1: Registry Services. Each proposed service has been previously approved by ICANN to ensure registry security and stability.

In addition the registry services found in Table 23-1, Merck Registry Holdings, Inc. is evaluating offering the following registry services:

1. Imposition of an annual cost recovery based fee to validate registrars that will be providing domain name registration services in the .MERCK gTLD.

2. The use of RFPs (Request for Proposals) and Auctions to determine string allocation in appropriate circumstances.

As further evidence of Verisign’s compliance with ICANN mandated security and stability requirements, Verisign allocates the applicable RFCs to each of the five customary registry services (items A – E above). For each registry service, Verisign also provides evidence in Figure 23 2 of Verisign’s RFC compliance and includes relevant ICANN prior-service approval actions.

See: Figure 23 2: ICANN RFC Compliance. Verisign currently operates TLDs in full compliance with each registry service’s applicable RFC(s). Each listed Verisign service has been previously approved by ICANN and is now operational on registries under Verisign management.

23.1.1 Critical Operations of the Registry

i. Receipt of Data from Registrars Concerning Registration of Domain Names and Name Servers
See Item A in Figure 23 1 and Figure 23 2.

ii. Provision to Registrars Status Information Relating to the Zone Servers
Verisign is Merck Registry Holdings, Inc.’s selected provider of backend registry services. Verisign registry services provisions to registrars status information relating to zone servers for the TLD. The services also allow a domain name to be updated with clientHold, serverHold status, which removes the domain name server details from zone files. This ensures that DNS queries of the domain name are not resolved temporarily. When these hold statuses are removed, the name server details are written back to zone files and DNS queries are again resolved. Figure 23 3 describes the domain name status information and zone insertion indicator provided to registrars. The zone insertion indicator determines whether the name server details of the domain name exist in the zone file for a given domain name status. Verisign also has the capability to withdraw domain names from the zone file in near-real time by changing the domain name statuses upon request by customers, courts, or legal authorities as required.
See: Figure 23 3: Zone Server Status Information. Verisign provisions to registrars status information related to the TLD.

iii. Dissemination of TLD Zone Files
See Item B in Figure 23 1 and Figure 23 2.

iv. Operation of the Registry Zone Servers
Verisign is Merck Registry Holdings, Inc.’s selected provider of backend registry services. Verisign, as a company, operates zone servers and serves DNS resolution from 76 geographically distributed resolution sites located in North America, South America, Africa, Europe, Asia, and Australia. Currently, 17 DNS locations are designated primary sites, offering greater capacity than smaller sites comprising the remainder of the Verisign constellation. Verisign also uses Anycast techniques and regional Internet resolution sites to expand coverage, accommodate emergency or surge capacity, and support system availability during maintenance procedures. Verisign operates Merck Registry Holdings, Inc.’s gTLD from a minimum of eight of its primary sites (two on the East Coast of the United States, two on the West Coast of the United States, two in Europe, and two in Asia) and expands resolution sites based on traffic volume and patterns. Further details of the geographic diversity of Verisign’s zone servers are provided in the response to Question 34, Geographic Diversity. Moreover, additional details of Verisign’s zone servers are provided in the response to Question 32, Architecture and the response to Question 35, DNS Service.
v. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations
See Item C in Figure 23 1 and Figure 23 2.

23.2 Other Products or Services the Registry Operator Is Required to Provide Because of the Establishment of a Consensus Policy

Verisign, Merck Registry Holdings, Inc.’s selected provider of backend registry services, is a proven supporter of ICANN’s consensus-driven, bottom-up policy development process whereby community members identify a problem, initiate policy discussions, and generate a solution that produces effective and sustained results. Verisign currently provides all of the products or services (collectively referred to as services) that the registry operator is required to provide because of the establishment of a Consensus Policy. For the .MERCK gTLD, Verisign implements these services using the same proven processes and procedures currently in-place for all registries under Verisign’s management. Furthermore, Verisign executes these services on computing platforms comparable to those of other registries under Verisign’s management. Verisign’s extensive experience with consensus policy required services and its proven processes to implement these services greatly minimize any potential risk to Internet security or stability. Details of these services are provided in the following subsections. It shall be noted that consensus policy services required of registrars (e.g., WHOIS Reminder, Expired Domain) are not included in this response. This exclusion is in accordance with the direction provided in the question’s Notes column to address registry operator services.

23.2.1 Inter-Registrar Transfer Policy (IRTP)
Technical Component: In compliance with the IRTP consensus policy, Verisign, Merck Registry Holdings, Inc.’s selected provider of backend registry services, has designed its registration systems to systematically restrict the transfer of domain names within 60 days of the initial create date. In addition, Verisign has implemented EPP and “AuthInfo” code functionality, which is used to further authenticate transfer requests. The registration system has been designed to enable compliance with the five-day Transfer grace period and includes the following functionality:
- Allows the losing registrar to proactively ‘ACK’ or acknowledge a transfer prior to the expiration of the five-day Transfer grace period
- Allows the losing registrar to proactively ‘NACK’ or not acknowledge a transfer prior to the expiration of the five-day Transfer grace period
- Allows the system to automatically ACK the transfer request once the five-day Transfer grace period has passed if the losing registrar has not proactively ACK’d or NACK’d the transfer request.

Business Component: All requests to transfer a domain name to a new registrar are handled according to the procedures detailed in the IRTP. Dispute proceedings arising from a registrarʹs alleged failure to abide by this policy may be initiated by any ICANN-accredited registrar under the Transfer Dispute Resolution Policy. Merck Registry Holdings, Inc.’s compliance office serves as the first-level dispute resolution provider pursuant to the associated Transfer Dispute Resolution Policy. As needed, Verisign is available to offer policy guidance as issues arise.
Security and Stability Concerns: Verisign is unaware of any impact, caused by the service, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems. By implementing the IRTP in accordance with ICANN policy, security is enhanced as all transfer commands are authenticated using the AuthInfo code prior to processing.

ICANN Prior Approval: Verisign has been in compliance with the IRTP since November 2004 and is available to support Merck Registry Holdings, Inc. in a consulting capacity as needed.
Unique to the TLD: This service is not provided in a manner unique to the .MERCK gTLD.

23.2.2 Add Grace Period (AGP) Limits Policy
Technical Component: Verisign’s registry system monitors registrars’ Add grace period deletion activity and provides reporting that permits Merck Registry Holdings, Inc. to assess registration fees upon registrars that have exceeded the AGP thresholds stipulated in the AGP Limits Policy. Further, Merck Registry Holdings, Inc. accepts and evaluates all exemption requests received from registrars and determines whether the exemption request meets the exemption criteria. Merck Registry Holdings, Inc. maintains all AGP Limits Policy exemption request activity so that this material may be included within Merck Registry Holdings, Inc.’s Monthly Registry Operator Report to ICANN.

Registrars that exceed the limits established by the policy may submit exemption requests to Merck Registry Holdings, Inc. for consideration. Merck Registry Holdings, Inc.’s compliance office reviews these exemption requests in accordance with the AGP Limits Policy and renders a decision. Upon request, Merck Registry Holdings, Inc. submits associated reporting on exemption request activity to support reporting in accordance with established ICANN requirements.

Business Component: The Add grace period (AGP) is restricted for any gTLD operator that has implemented an AGP. Specifically, for each operator:
- During any given month, an operator may not offer any refund to an ICANN-accredited registrar for any domain names deleted during the AGP that exceed (i) 10 percent of that registrarʹs net new registrations (calculated as the total number of net adds of one-year through ten-year registrations as defined in the monthly reporting requirement of Operator Agreements) in that month, or (ii) fifty (50) domain names, whichever is greater, unless an exemption has been granted by an operator.
- Upon the documented demonstration of extraordinary circumstances, a registrar may seek from an operator an exemption from such restrictions in a specific month. The registrar must confirm in writing to the operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside the registrarʹs control. Acceptance of any exemption will be at the sole and reasonable discretion of the operator; however ʺextraordinary circumstancesʺ that reoccur regularly for the same registrar will not be deemed extraordinary.

In addition to all other reporting requirements to ICANN, Merck Registry Holdings, Inc. identifies each registrar that has sought an exemption, along with a brief description of the type of extraordinary circumstance and the action, approval, or denial that the operator took.

Security and Stability Concerns: Verisign is unaware of any impact, caused by the policy, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems.
ICANN Prior Approval: Verisign, Merck Registry Holdings, Inc.’s backend registry services provider, has had experience with this policy since its implementation in April 2009 and is available to support Merck Registry Holdings, Inc. in a consulting capacity as needed.
Unique to the TLD: This service is not provided in a manner unique to the .MERCK gTLD.

23.2.3 Registry Services Evaluation Policy (RSEP)
Technical Component: Verisign, Merck Registry Holdings, Inc.’s selected provider of backend registry services, adheres to all RSEP submission requirements. Verisign has followed the process many times and is fully aware of the submission procedures, the type of documentation required, and the evaluation process that ICANN adheres to.
Business Component: In accordance with ICANN procedures detailed on the ICANN RSEP website (http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄), all gTLD registry operators are required to follow this policy when submitting a request for new registry services.
Security and Stability Concerns: As part of the RSEP submission process, Verisign, Merck Registry Holdings, Inc.’s backend registry services provider, identifies any potential security and stability concerns in accordance with RSEP stability and security requirements. Verisign never launches services without satisfactory completion of the RSEP process and resulting approval.
ICANN Prior Approval: Not applicable.
Unique to the TLD: gTLD RSEP procedures are not implemented in a manner unique to the .MERCK gTLD.

23.3 Products or Services Only a Registry Operator Is Capable of Providing by Reason of Its Designation As the Registry Operator

Verisign, Merck Registry Holdings, Inc.’s selected backend registry services provider, has developed a Registry-Registrar Two-Factor Authentication Service that complements traditional registration and resolution registry services. In accordance with direction provided in Question 23, Verisign details below the technical and business components of the service, identifies any potential threat to registry security or stability, and lists previous interactions with ICANN to approve the operation of the service. The Two-Factor Authentication Service is currently operational, supporting multiple registries under ICANN’s purview.

Merck Registry Holdings, Inc. is unaware of any competition issue that may require the registry service(s) listed in this response to be referred to the appropriate governmental competition authority or authorities with applicable jurisdiction. ICANN previously approved the service(s), at which time it was determined that either the service(s) raised no competitive concerns or any applicable concerns related to competition were satisfactorily addressed.

23.3.1 Two-Factor Authentication Service
Technical Component: The Registry-Registrar Two-Factor Authentication Service is designed to improve domain name security and assist registrars in protecting the accounts they manage. As part of the service, dynamic one-time passwords augment the user names and passwords currently used to process update, transfer, and⁄or deletion requests. These one-time passwords enable transaction processing to be based on requests that are validated both by “what users know” (i.e., their user name and password) and “what users have” (i.e., a two-factor authentication credential with a one-time-password).

Q.24 – Shared Registration System (SRS) Performance

24.1 Robust Plan for Operating a Reliable SRS

24.1.1 High-Level Shared Registration System (SRS) System Description

VeriSign, Inc. (ʺVerisignʺ), Merck Registry Holdings, Inc.’s selected provider of back-end registry services, provides and operates a robust and reliable SRS that enables multiple registrars to provide domain name registration services in the top-level domain (TLD). Verisign’s proven reliable SRS serves approximately 915 registrars, and Verisign, as a company, has averaged more than 140 million registration transactions per day. The SRS provides a scalable, fault-tolerant platform for the delivery of gTLDs through the use of a central customer database, a Web interface, a standard provisioning protocol (i.e., Extensible Provisioning Protocol, ʺEPPʺ), and a transport protocol (i.e., Secure Sockets Layer, ʺSSLʺ).

The SRS components include:

-Web Interface: Allows customers to access the authoritative database for accounts, contacts, users, authorization groups, product catalog, product subscriptions, and customer notification messages.

-EPP Interface: Provides an interface to the SRS that enables registrars to use EPP to register and manage domains, hosts, and contacts.

-Authentication Provider: A Verisign-developed application, specific to the SRS, that authenticates a user based on a login name, password, and the SSL certificate common name and client IP address.

The SRS is designed to be scalable and fault tolerant by incorporating clustering in multiple tiers of the platform. New nodes can be added to a cluster within a single tier to scale a specific tier, and if one node fails within a single tier, the services will still be available. The SRS allows registrars to manage the .MERCK gTLD domain names in a single architecture.

To flexibly accommodate the scale of its transaction volumes, as well as new technologies, Verisign employs the following design practices:

-Scale for Growth: Scale to handle current volumes and projected growth.

-Scale for Peaks: Scale to twice base capacity to withstand “registration add attacks” from a compromised registrar system.

-Limit Database CPU Utilization: Limit utilization to no more than 50 percent during peak loads.

-Limit Database Memory Utilization: Each user’s login process that connects to the database allocates a small segment of memory to perform connection overhead, sorting, and data caching. Verisign’s standards mandate that no more than 40 percent of the total available physical memory on the database server will be allocated for these functions.

Verisign’s SRS is built upon a three-tier architecture as illustrated in Figure 24-1 and detailed here.

(See Figure 24-1, SRS Architecture: Verisign’s SRS is hierarchically designed to meet the forecasted registration volume of the .MERCK gTLD, and it can be scaled to meet future registration volume increases.)

-Gateway Layer: The first tier, the gateway servers, uses EPP to communicate with registrars. These gateway servers then interact with application servers, which comprise the second tier.

-Application Layer: The application servers contain business logic for managing and maintaining the registry business. The business logic is particular to each TLD’s business rules and requirements. The flexible internal design of the application servers allows Verisign to easily leverage existing business rules to apply to the .MERCK gTLD. The application servers store Merck Registry Holdings, Inc.’s data in the registry database, which comprises the third and final tier. This simple, industry-standard design has been highly effective with other customers for whom Verisign provides backend registry services.

-Database Layer: The database is the heart of this architecture. It stores all the essential information provisioned from registrars through the gateway servers. Separate servers query the database, extract updated zone and WHOIS information, validate that information, and distribute it around the clock to Verisign’s worldwide domain name resolution sites.

-Scalability and Performance: Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, implements its scalable SRS on a supportable infrastructure that achieves the availability requirements in Specification 10. Verisign employs the design patterns of simplicity and parallelism in both its software and systems, based on its experience that these factors contribute most significantly to scalability and reliable performance. Going counter to feature-rich development patterns, Verisign intentionally minimizes the number of lines of code between the end-user and the data delivered. The result is a network of restorable components that provide rapid, accurate updates. Figure 24-2 depicts EPP traffic flows and local redundancy in Verisign’s SRS provisioning architecture. As detailed in the figure, local redundancy is maintained for each layer as well as each piece of equipment. This built-in redundancy enhances operational performance while enabling the future system scaling necessary to meet additional demand created by this or future registry applications.

(See Figure 24-2, Built-in SRS Redundancy: Verisign’s SRS system is built upon multiple layers of redundancy to ensure the system remains highly available.)

Besides improving scalability and reliability, local SRS redundancy enables Verisign to take down individual system components for maintenance and upgrades, with little to no performance impact. With Verisign’s redundant design, Verisign can perform routine maintenance while the remainder of the system remains online and unaffected. For the .MERCK gTLD registry, this flexibility minimizes unplanned downtime and provides a more consistent end-user experience.

24.1.2 Representative Network Diagrams

Figure 24-3 provides a summary network diagram of Merck Registry Holdings, Inc.’s selected back-end registry services provider’s (Verisign’s) SRS. This configuration at both the primary and alternate-primary Verisign data centers provides a highly reliable backup capability. Data is continuously replicated between both sites to ensure failover to the alternate-primary site can be implemented expeditiously to support both planned and unplanned outages.

(See Figure 24-3, SRS Network Diagram: Verisign’s fully redundant SRS design and geographically separated data centers help ensure service level availability requirements are met.)

24.1.3 Number of Servers

As Merck Registry Holdings, Inc.’s selected provider of back-end registry services, Verisign continually reviews its server deployments for all aspects of its registry service. Verisign evaluates usage based on peak performance objectives as well as current transaction volumes, which drive the quantity of servers in its implementations. Verisign’s scaling is based on the following factors:
Server configuration is based on CPU, memory, disk IO, total disk, and network throughput projections.

Server quantity is determined through statistical modeling to fulfill overall performance objectives as defined by both the service availability and the server configuration.

To ensure continuity of operations for the .MERCK gTLD, Verisign uses a minimum of 100 dedicated servers per SRS site. These servers are virtualized to meet demand.

24.1.4 Description of Interconnectivity with Other Registry Systems

Figure 24-4 provides a technical overview of the Merck Registry Holdings, Inc.’s selected back-end registry services provider’s (Verisign’s) SRS, showing how the SRS component fits into this larger system and interconnects with other system components.

(See Figure 24-4, Technical Overview: Verisign’s SRS provides the registrar-facing component of the system establishing the zone file needed to enable DNS and WHOIS services.)

24.1.5 Frequency of Synchronization Between Servers

As Merck Registry Holdings, Inc.’s selected provider of back-end registry services, Verisign uses synchronous replication to keep the Verisign SRS continuously in sync between the two data centers. This synchronization is performed in near-real time, thereby supporting rapid failover should a failure occur or a planned maintenance outage be required.

24.1.6 Synchronization Scheme

Verisign uses synchronous replication to keep the Verisign SRS continuously in sync between the two data centers. Because the alternate-primary site is continuously up, and built using an identical design to the primary data center, it is classified as a “hot standby.”

24.2 Scalability and Performance Are Consistent with the overall business approach and planned size of the registry

Verisign is an experienced back-end registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.

Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .MERCK gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the ʺMost Likelyʺ scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the back-end registry services it provides to Merck Registry Holdings, Inc. fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response of this application.

24.3 Technical plan that is adequately resourced in the planned costs detailed in the financial section

Verisign, the Merck Registry Holdings, Inc.’s selected provider of back-end registry services, is an experienced back-end registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the ʺMost Likelyʺ scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the back-end registry services provided to Merck Registry Holdings, Inc. fully accounts for this personnel-related cost, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response of this application.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .COM, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31 of this application, Technical Overview of Proposed Registry, to support SRS performance:

-Application Engineers: 19
-Database Administrators: 8
-Database Engineers: 3
-Network Administrators: 11
-Network Architects: 4
-Project Managers: 25
-Quality Assurance Engineers: 11
-SRS System Administrators: 13
-Storage Administrators: 4
-Systems Architects: 9

To implement and manage the .MERCK gTLD as described in this application, Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .COM and .NET). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes startup learning curves and helps ensure that new staff members properly execute their duties.

24.4 Evidence of Compliance with Specification 6 and 10 to the Registry Agreement

24.4.1 Section 1.2 (EPP) of Specification 6, Registry Interoperability and Continuity Specifications

Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, provides these services using its SRS, which complies fully with Specification 6, Section 1.2 of the Registry Agreement. In using its SRS to provide back-end registry services, Verisign implements and complies with relevant existing RFCs (i.e., 5730, 5731, 5732, 5733, 5734, and 5910) and intends to comply with RFCs that may be published in the future by the Internet Engineering Task Force (IETF), including successor standards, modifications, or additions thereto relating to the provisioning and management of domain names that use EPP. In addition, Verisign’s SRS includes a Registry Grace Period (RGP) and thus complies with RFC 3915 and its successors. Details of the Verisign SRS’ compliance with RFC SRS⁄EPP are provided in the response to Question 25, Extensible Provisioning Protocol, of this application. Verisign does not use functionality outside the base EPP RFCs, although proprietary EPP extensions are documented in Internet-Draft format following the guidelines described in RFC 3735 within the response to Question 25 of this application. Moreover, prior to deployment, Merck Registry Holdings, Inc. will provide to ICANN updated documentation of all the EPP objects and extensions supported in accordance with Specification 6, Section 1.2.

24.4.2 Specification 10, EPP Registry Performance Specifications

Verisign’s SRS meets all EPP Registry Performance Specifications detailed in Specification 10, Section 2. Evidence of this performance can be verified by a review of the .COM and .NET Registry Operator’s Monthly Reports, which Verisign files with ICANN. These reports detail Verisign’s operational status of the .COM and .NET registries, which use an SRS design and approach comparable to the one proposed for the .MERCK gTLD. These reports provide evidence of Verisign’s ability to meet registry operation service level agreements (SLAs) comparable to those detailed in Specification 10. The reports are accessible at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

In accordance with EPP Registry Performance Specifications detailed in Specification 10, Verisignʹs SRS meets the following performance attributes:

-EPP service availability: ≤ 864 minutes of downtime (≈98%)
-EPP session-command round trip time (RTT): ≤4000 milliseconds (ms), for at least 90 percent of the commands
-EPP query-command RTT: ≤2000 ms, for at least 90 percent of the commands
-EPP transform-command RTT: ≤4000 ms, for at least 90 percent of the commands

Registrars can use the one-time-password when communicating directly with Verisign’s Customer Service department as well as when using the registrar portal to make manual updates, transfers, and⁄or deletion transactions. The Two-Factor Authentication Service is an optional service offered to registrars that execute the Registry-Registrar Two-Factor Authentication Service Agreement.

Business Component: There is no charge for the Registry-Registrar Two-Factor Authentication Service. It is enabled only for registrars that wish to take advantage of the added security provided by the service.
Security and Stability Concerns: Verisign is unaware of any impact, caused by the service, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems. The service is intended to enhance domain name security, resulting in increased confidence and trust by registrants.
ICANN Prior Approval: ICANN approved the same Two-Factor Authentication Service for Verisign’s use on .COM and .NET on 10 July 2009 (RSEP Proposal 2009004) and for .NAME on 16 February 2011 (RSEP Proposal 2011001).

Unique to the TLD: This service is not provided in a manner unique to the .MERCK gTLD.

Q.25 – Extensible Provisioning Protocol (EPP)

25.1 Complete knowledge and understanding of this aspect of registry technical requirements
VeriSign, Inc. (“Verisign’), Merck Registry Holdings, Inc.’s selected back-end registry services provider, has used Extensible Provisioning Protocol (EPP) since its inception and possesses complete knowledge and understanding of EPP registry systems. Its first EPP implementation – for a thick registry for the .NAME generic top-level domain (gTLD) – was in 2002. Since then Verisign has continued its RFC-compliant use of EPP in multiple TLDs. as detailed in Figure 25-1.

(See: Figure 25 1: EPP Implementations. Verisign has repeatedly proven its ability to successfully implement EPP for both small and large registries.)

Verisign’s understanding of EPP and its ability to implement code that complies with the applicable RFCs is unparalleled. Mr. Scott Hollenbeck, Verisign’s director of software development, authored the Extensible Provisioning Protocol and continues to be fully engaged in its refinement and enhancement (U.S. Patent Number 7299299 – Shared registration system for registering domain names). Verisign has also developed numerous new object mappings and object extensions following the guidelines in RFC 3735 (Guidelines for Extending the Extensible Provisioning Protocol). Mr. James Gould, a principal engineer at Verisign, led and co-authored the most recent EPP Domain Name System Security Extensions (DNSSEC) RFC effort (RFC 5910).

All registry systems for which Verisign is the registry operator or provides back-end registry services use EPP. Upon approval of this application, Verisign will use EPP to provide the back-end registry services for this gTLD. The .COM, .NET, and .NAME registries for which Verisign is the registry operator use an SRS design and approach comparable to the one proposed for this gTLD. Approximately 915 registrars use the Verisign EPP service, and the registry system performs more than 140 million EPP transactions daily without performance issues or restrictive maintenance windows. The processing time service level agreement (SLA) requirements for the Verisign-operated .NET gTLD are the strictest of the current Verisign managed gTLDs. All processing times for Verisign-operated gTLDs can be found in ICANN’s Registry Operator’s Monthly Reports at http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

Verisign has also been active on the Internet Engineering Task Force (IETF) Provisioning Registry Protocol (provreg) working group and mailing list since work started on the EPP protocol in 2000. This working group provided a forum for members of the Internet community to comment on Mr. Scott Hollenbeck’s initial EPP drafts, which Mr. Hollenbeck refined based on input and discussions with representatives from registries, registrars, and other interested parties. The working group has since concluded, but the mailing list is still active to enable discussion of different aspects of EPP.

25.1.1 EPP Interface with Registrars

Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, fully supports the features defined in the EPP specifications and provides a set of software development kits (SDK) and tools to help registrars build secure and stable interfaces. Verisign’s SDKs give registrars the option of either fully writing their own EPP client software to integrate with the Shared Registration System (SRS), or using the Verisign-provided SDKs to aid them in the integration effort. Registrars can download the Verisign EPP SDKs and tools from the registrar website (http:⁄⁄www.Verisign.com⁄domain-name-services⁄current-registrars⁄epp-sdk⁄index.html).
The EPP SDKs provide a host of features including connection pooling, Secure Sockets Layer (SSL), and a test server (stub server) to run EPP tests against. One tool—the EPP tool—provides a web interface for creating EPP Extensible Markup Language (XML) commands and sending them to a configurable set of target servers. This helps registrars in creating the template XML and testing a variety of test cases against the EPP servers. An Operational Test and Evaluation (OT&E) environment, which runs the same software as the production system so approved registrars can integrate and test their software before moving into a live production environment, is also available.

25.2 Technical plan scope⁄scale consistent with the overall business approach and planned size of the registry

Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, is an experienced back-end registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.

Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .MERCK gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the back-end registry services it provides to Merck Registry Holdings, Inc. fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

25.3 Technical plan that is adequately resourced in the planned costs detailed in the financial section

Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, is an experienced back-end registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance.

Verisign’s pricing for the back-end registry services it provides to Merck Registry Holdings, Inc. fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support the provisioning of EPP services:
- Application Engineers: 19
- Database Engineers: 3
- Quality Assurance Engineers: 11

To implement and manage the .MERCK gTLD as described in this application, Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .COM and .NET). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.

25.4 Ability to comply with Relevant RFCs

Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, incorporates design reviews, code reviews, and peer reviews into its software development lifecycle (SDLC) to ensure compliance with the relevant RFCs. Verisign’s dedicated QA team creates extensive test plans and issues internal certifications when it has confirmed the accuracy of the code in relation to the RFC requirements. Verisign’s QA organization is independent from the development team within engineering. This separation helps Verisign ensure adopted processes and procedures are followed, further ensuring that all software releases fully consider the security and stability of the TLD.

For the .MERCK gTLD, the Shared Registration System (SRS) complies with the following IETF EPP specifications, where the XML templates and XML schemas are defined in the following specifications:
- EPP RGP 3915 (http:⁄⁄www.apps.ietf.org⁄rfc⁄rfc3915.html): EPP Redemption Grace Period (RGP) Mapping specification for support of RGP statuses and support of Restore Request and Restore Report (authored by Verisign’s Scott Hollenbeck)
- EPP 5730 (http:⁄⁄tools.ietf.org⁄html⁄rfc5730): Base EPP specification (authored by Verisign’s Scott Hollenbeck)
- EPP Domain 5731 (http:⁄⁄tools.ietf.org⁄html⁄rfc5731): EPP Domain Name Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP Host 5732 (http:⁄⁄tools.ietf.org⁄html⁄rfc5732): EPP Host Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP Contact 5733 (http:⁄⁄tools.ietf.org⁄html⁄rfc5733): EPP Contact Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP TCP 5734 (http:⁄⁄tools.ietf.org⁄html⁄rfc5734): EPP Transport over Transmission Control Protocol (TCP) specification (authored by Verisign’s Scott Hollenbeck)
- EPP DNSSEC 5910 (http:⁄⁄tools.ietf.org⁄html⁄rfc5910): EPP Domain Name System Security Extensions (DNSSEC) Mapping specification (authored by Verisign’s James Gould and Scott Hollenbeck)

25.5 Proprietary EPP Extensions

Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, uses its SRS to provide registry services. The SRS supports the following EPP specifications, which Verisign developed following the guidelines in RFC 3735, where the XML templates and XML schemas are defined in the specifications:
- IDN Language Tag (http:⁄⁄www.verisigninc.com⁄assets⁄idn-language-tag.pdf): EPP internationalized domain names (IDN) language tag extension used for IDN domain name registrations
- RGP Poll Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf): EPP mapping for an EPP poll message in support of Restore Request and Restore Report
- WHOIS Info Extension (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf): EPP extension for returning additional information needed for transfers
- EPP ConsoliDate Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt): EPP mapping to support a Domain Sync operation for synchronizing domain name expiration dates
- NameStore Extension (http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf): EPP extension for routing with an EPP intelligent gateway to a pluggable set of back-end products and services
- Low Balance Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf): EPP mapping to support low balance poll messages that proactively notify registrars of a low balance (available credit) condition

As part of the 2006 implementation report to bring the EPP RFC documents from Proposed Standard status to Draft Standard status, an implementation test matrix was completed. Two independently developed EPP client implementations based on the RFCs were tested against the Verisign EPP server for the domain, host, and contact transactions. No compliance-related issues were identified during this test, providing evidence that these extensions comply with RFC 3735 guidelines and further demonstrating Verisign’s ability to design, test, and deploy an RFC-compliant EPP implementation.

25.5.1 EPP Templates and Schemas

The EPP XML schemas are formal descriptions of the EPP XML templates. They are used to express the set of rules to which the EPP templates must conform in order to be considered valid by the schema. The EPP schemas define the building blocks of the EPP templates, describing the format of the data and the different EPP commands’ request and response formats. The current EPP implementations managed by Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, use these EPP templates and schemas, as will the proposed TLD. For each proprietary XML template⁄schema Verisign provides a reference to the applicable template and includes the schema.

25.5.1.1 XML templates⁄schema for idnLang-1.0
Template: The templates for idnLang-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄idn-language-tag.pdf.
Schema: This schema describes the extension mapping for the IDN language tag. The mapping extends the EPP domain name mapping to provide additional features required for the provisioning of IDN domain name registrations.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄idnLang-1.0ʺ
xmlns:idnLang=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄idnLang-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0 domain name
extension schema for IDN Lang Tag.
〈⁄documentation〉
〈⁄annotation〉

〈!--
Child elements found in EPP commands.
--〉
〈element name=ʺtagʺ type=ʺlanguageʺ⁄〉

〈!--
End of schema.
--〉
〈⁄schema〉

25.5.1.2 XML templates⁄schema for rgp-poll-1.0
Template: The templates for rgp-poll-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄rgp-poll-mapping.pdf.
Schema: This schema describes the extension mapping for poll notifications. The mapping extends the EPP base mapping to provide additional features for registry grace period (RGP) poll notifications.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄rgp-poll-1.0ʺ
xmlns:rgp-poll=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄rgp-poll-1.0ʺ
xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
xmlns:rgp=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈!--
Import common element types.
--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉
〈import namespace=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ
schemaLocation=ʺrgp-1.0.xsdʺ⁄〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
Verisign poll notification specification for registry grace period
poll notifications.
〈⁄documentation〉
〈⁄annotation〉

〈!--
Child elements found in EPP commands.
--〉
〈element name=ʺpollDataʺ type=ʺrgp-poll:pollDataTypeʺ⁄〉

〈!--
Child elements of the 〈notifyData〉 element for the
redemption grace period.
--〉
〈complexType name=ʺpollDataTypeʺ〉
〈sequence〉
〈element name=ʺnameʺ type=ʺeppcom:labelTypeʺ⁄〉
〈element name=ʺrgpStatusʺ type=ʺrgp:statusTypeʺ⁄〉
〈element name=ʺreqDateʺ type=ʺdateTimeʺ⁄〉
〈element name=ʺreportDueDateʺ type=ʺdateTimeʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉
〈
!--
End of schema.
--〉
〈⁄schema〉

25.5.1.3 XML templates⁄schema for whoisInf-1.0
Template: The templates for whoisInf-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf.
Schema: This schema describes the extension mapping for the Whois Info extension. The mapping extends the EPP domain name mapping to provide additional features for returning additional information needed for transfers.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄whoisInf-1.0ʺ
xmlns:whoisInf=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄whoisInf-1.0ʺ
xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
extension schema for Whois Info
〈⁄documentation〉
〈⁄annotation〉

〈!--
Possible Whois Info extension root elements.
--〉
〈element name=ʺwhoisInfʺ type=ʺwhoisInf:whoisInfTypeʺ⁄〉
〈element name=ʺwhoisInfDataʺ type=ʺwhoisInf:whoisInfDataTypeʺ⁄〉

〈!--
Child elements for the 〈whoisInf〉 extension which
is used as an extension to an info command.
--〉
〈complexType name=ʺwhoisInfTypeʺ〉
〈sequence〉
〈element name=ʺflagʺ type=ʺbooleanʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈!--
Child elements for the 〈whoisInfData〉 extension which
is used as an extension to the info response.
--〉
〈complexType name=ʺwhoisInfDataTypeʺ〉
〈sequence〉
〈element name=ʺregistrarʺ type=ʺstringʺ⁄〉
〈element name=ʺwhoisServerʺ type=ʺeppcom:labelTypeʺ
minOccurs=ʺ0ʺ⁄〉
〈element name=ʺurlʺ type=ʺtokenʺ minOccurs=ʺ0ʺ⁄〉
〈element name=ʺirisServerʺ type=ʺeppcom:labelTypeʺ
minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈⁄schema〉

25.5.1.4 XML templates⁄schema for sync-1.0 (consoliDate)
Template: The templates for sync-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt.
Schema: This schema describes the extension mapping for the synchronization of domain name registration period expiration dates. This service is known as ʺConsoliDate.ʺ The mapping extends the EPP domain name mapping to provide features that allow a protocol client to end a domain name registration period on a specific month and day.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄sync-1.0ʺ
xmlns:sync=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄sync-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0 domain name
extension schema for expiration date synchronization.
〈⁄documentation〉
〈⁄annotation〉

〈!--
Child elements found in EPP commands.
--〉
〈element name=ʺupdateʺ type=ʺsync:updateTypeʺ⁄〉

〈!--
Child elements of the 〈update〉 command.
--〉
〈complexType name=ʺupdateTypeʺ〉
〈sequence〉
〈element name=ʺexpMonthDayʺ type=ʺgMonthDayʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈!--
End of schema.
--〉
〈⁄schema〉

25.5.1.5 XML templates⁄schema for namestoreExt-1.1
Template: The templates for namestoreExt-1.1 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf.
Schema: This schema describes the extension mapping for the routing with an EPP intelligent gateway to a pluggable set of back-end products and services. The mapping extends the EPP domain name and host mapping to provide a sub-product identifier to identify the target sub-product that the EPP operation is intended for.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign-grs.com⁄epp⁄namestoreExt-1.1ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
xmlns:namestoreExt=ʺhttp:⁄⁄www.Verisign-grs.com⁄epp⁄namestoreExt-1.1ʺ
elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0 Namestore extension schema
for destination registry routing.
〈⁄documentation〉
〈⁄annotation〉

〈!-- General Data types. --〉
〈simpleType name=ʺsubProductTypeʺ〉
〈restriction base=ʺtokenʺ〉
〈minLength value=ʺ1ʺ⁄〉
〈maxLength value=ʺ64ʺ⁄〉
〈⁄restriction〉
〈⁄simpleType〉

〈complexType name=ʺextAnyTypeʺ〉
〈sequence〉
〈any namespace=ʺ##otherʺ maxOccurs=ʺunboundedʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈!-- Child elements found in EPP commands and responses. --〉
〈element name=ʺnamestoreExtʺ type=ʺnamestoreExt:namestoreExtTypeʺ⁄〉

〈!-- Child elements of the 〈product〉 command. --〉
〈complexType name=ʺnamestoreExtTypeʺ〉
〈sequence〉
〈element name=ʺsubProductʺ
type=ʺnamestoreExt:subProductTypeʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈!-- Child response elements. --〉
〈element name=ʺnsExtErrDataʺ type=ʺnamestoreExt:nsExtErrDataTypeʺ⁄〉

〈!-- 〈prdErrData〉 error response elements. --〉
〈complexType name=ʺnsExtErrDataTypeʺ〉
〈sequence〉
〈element name=ʺmsgʺ type=ʺnamestoreExt:msgTypeʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈!-- 〈prdErrData〉〈msg〉 element. --〉
〈complexType name=ʺmsgTypeʺ〉
〈simpleContent〉
〈extension base=ʺnormalizedStringʺ〉
〈attribute name=ʺcodeʺ
type=ʺnamestoreExt:prdErrCodeTypeʺ use=ʺrequiredʺ⁄〉
〈attribute name=ʺlangʺ type=ʺlanguageʺ default=ʺenʺ⁄〉
〈⁄extension〉
〈⁄simpleContent〉
〈⁄complexType〉

〈!-- 〈prdErrData〉 error response codes. --〉
〈simpleType name=ʺprdErrCodeTypeʺ〉
〈restriction base=ʺunsignedShortʺ〉
〈enumeration value=ʺ1ʺ⁄〉
〈⁄restriction〉
〈⁄simpleType〉

〈!-- End of schema. --〉
〈⁄schema〉

25.5.1.6 XML templates⁄schema for lowbalance-poll-1.0
Template: The templates for lowbalance-poll-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf.
Schema: This schema describes the extension mapping for the account low balance notification. The mapping extends the EPP base mapping so an account holder can be notified via EPP poll messages whenever the available credit for an account reaches or goes below the credit threshold.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄lowbalance-poll-1.0ʺ
xmlns:lowbalance-poll=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄lowbalance-poll-1.0ʺ
xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈!-- Import common element types.--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
Verisign poll notification specification for low balance notifications.
〈⁄documentation〉
〈⁄annotation〉

〈!--Child elements found in EPP commands.--〉
〈element name=ʺpollDataʺ type=ʺlowbalance-poll:pollDataTypeʺ⁄〉

〈!--Child elements of the 〈notifyData〉 element for the low balance.--〉
〈complexType name=ʺpollDataTypeʺ〉
〈sequence〉
〈element name=ʺregistrarNameʺ type=ʺeppcom:labelTypeʺ⁄〉
〈element name=ʺcreditLimitʺ type=ʺnormalizedStringʺ⁄〉
〈element name=ʺcreditThresholdʺ
type=ʺlowbalance-poll:thresholdTypeʺ⁄〉
〈element name=ʺavailableCreditʺ type=ʺnormalizedStringʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈complexType name=ʺthresholdTypeʺ〉
〈simpleContent〉
〈extension base=ʺnormalizedStringʺ〉
〈attribute name=ʺtypeʺ
type=ʺlowbalance-poll:thresholdValueTypeʺ
use=ʺrequiredʺ⁄〉
〈⁄extension〉
〈⁄simpleContent〉
〈⁄complexType〉

〈simpleType name=ʺthresholdValueTypeʺ〉
〈restriction base=ʺtokenʺ〉
〈enumeration value=ʺFIXEDʺ⁄〉
〈enumeration value=ʺPERCENTʺ⁄〉
〈⁄restriction〉
〈⁄simpleType〉

〈!-- End of schema.--〉
〈⁄schema〉

25.6 Proprietary EPP Extension Consistency with Registration Lifecycle

Merck Registry Holdings, Inc.’s selected back-end registry services provider’s (Verisign’s) proprietary EPP extensions, defined in Section 5 above, are consistent with the registration lifecycle documented in the response to Question 27, Registration Lifecycle. Details of the registration lifecycle are presented in that response. As new registry features are required, Verisign develops proprietary EPP extensions to address new operational requirements. Consistent with ICANN procedures Verisign adheres to all applicable Registry Services Evaluation Process (RSEP) procedures.

Q.26 – WHOIS

26.1 Complete knowledge and understanding of this aspect of registry technical requirements
VeriSign, Inc. (ʺVerisignʺ) Merck Registry Holdings, Inc. (“MRH”)’s selected back-end registry services provider, has operated the WHOIS lookup service for the gTLDs and ccTLDs it manages since 1991, and will provide these proven services for the .MERCK gTLD registry. In addition, it continues to work with the Internet community to improve the utility of WHOIS data, while thwarting its application for abusive uses.

26.1.1 High-Level WHOIS System Description
Like all other components of MRH’s selected back-end registry services provider’s (Verisign’s) registry service, Verisign’s WHOIS system is designed and built for both reliability and performance in full compliance with applicable RFCs. Verisign’s current WHOIS implementation has answered more than five billion WHOIS queries per month for the TLDs it manages, and has experienced more than 250,000 queries per minute in peak conditions. The proposed gTLD uses a WHOIS system design and approach that is comparable to the current implementation. Independent quality control testing ensures Verisign’s WHOIS service is RFC-compliant through all phases of its lifecycle.
Verisignʹs redundant WHOIS databases further contribute to overall system availability and reliability. The hardware and software for its WHOIS service is architected to scale both horizontally (by adding more servers) and vertically (by adding more CPUs and memory to existing servers) to meet future need.
Verisign can fine-tune access to its WHOIS database on an individual Internet Protocol (IP) address basis, and it works with registrars to help ensure their services are not limited by any restriction placed on WHOIS. Verisign provides near real-time updates for WHOIS services for the TLDs under its management. As information is updated in the registration database, it is propagated to the WHOIS servers for quick publication. These updates align with the near real-time publication of Domain Name System (DNS) information as it is updated in the registration database. This capability is important for the .MERCK gTLD registry as it is Verisign’s experience that when DNS data is updated in near real time, so should WHOIS data be updated to reflect the registration specifics of those domain names.
Verisign’s WHOIS response time has been less than 500 milliseconds for 95 percent of all WHOIS queries in .COM, .NET, .TV, and .CC. The response time in these TLDs, combined with Verisign’s capacity, enables the WHOIS system to respond to up to 30,000 searches (or queries) per second for a total capacity of 2.6 billion queries per day.

The WHOIS software written by Verisign complies with RFC 3912. Verisign uses an advanced in-memory database technology to provide exceptional overall system performance and security. In accordance with RFC 3912, Verisign provides a website at whois.nic.MERCK that provides free public query-based access to the registration data.
Verisign currently operates both thin and thick WHOIS systems.

Verisign commits to implementing a RESTful WHOIS service upon finalization of agreements with the IETF (Internet Engineering Task Force).
26.1.1a Provided Functionalities for User Interface

To use the WHOIS service via port 43, the user enters the applicable parameter on the command line as illustrated here:

-For domain name: whois EXAMPLE.TLD
-For registrar: whois ʺregistrar Example Registrar, Inc.ʺ
-For name server: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺname server (IP address)ʺ

To use the WHOIS service via the Web-based directory service search interface:
-Go to http:⁄⁄whois.nic.MERCK
-Click on the appropriate button (Domain, Registrar, or Name Server)
-Enter the applicable parameter:
--Domain name, including the TLD (e.g., EXAMPLE.TLD)
--Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)
--Full host name or the IP address (e.g., NS1.EXAMPLE.TLD or 198.41.3.39)
-Click on the Submit button.

26.1.1b Provisions to Ensure That Access Is Limited to Legitimate Authorized Users and Is in Compliance with Applicable Privacy Laws or Policies
To further promote reliable and secure WHOIS operations, Verisign, MRH’s selected back-end registry services provider, has implemented rate-limiting characteristics within the WHOIS service software. For example, to prevent data mining or other abusive behavior, the service can throttle a specific requestor if the query rate exceeds a configurable threshold. In addition, QoS technology enables rate limiting of queries before they reach the servers, which helps protect against denial of service (DoS) and distributed denial of service (DDoS) attacks.
Verisign’s software also permits restrictions on search capabilities. For example, wild card searches can be disabled. If needed, it is possible to temporarily restrict and⁄or block requests coming from specific IP addresses for a configurable amount of time. Additional features that are configurable in the WHOIS software include help files, headers and footers for WHOIS query responses, statistics, and methods to memory map the database. Furthermore, Verisign is European Union (EU) Safe Harbor certified and has worked with European data protection authorities to address applicable privacy laws by developing a tiered WHOIS access structure that requires users who require access to more extensive data to (i) identify themselves, (ii) confirm that their use is for a specified purpose and (iii) enter into an agreement governing their use of the more extensive WHOIS data.
26.1.2 Relevant Network Diagrams
Figure 26-1 provides a summary network diagram of the WHOIS service provided by Verisign, MRH’s selected back-end registry services provider. The figure details the configuration with one resolution⁄WHOIS site. For the .MERCK gTLD, Verisign provides WHOIS service from six of its 17 primary sites based on the proposed gTLD’s traffic volume and patterns. A functionally equivalent resolution architecture configuration exists at each WHOIS site.
26.1.3 IT and Infrastructure Resources
Figure 26-2 summarizes the IT and infrastructure resources that Verisign, MRH’s selected back-end registry services provider, uses to provision WHOIS services from Verisign primary resolution sites. As needed, virtual machines are created based on actual and projected demand.
See Figure 26-2
26.1.4 Description of Interconnectivity with Other Registry Systems
Figure 26-3 provides a technical overview of the registry system provided by Verisign, MRH’s selected back-end registry services provider, and shows how the WHOIS service component fits into this larger system and interconnects with other system components.

26.1.5 Frequency of Synchronization Between Servers
Synchronization between the SRS and the geographically distributed WHOIS resolution sites occurs approximately every three minutes. Verisign, MRH’s selected back-end registry services provider, uses a two-part WHOIS update process to ensure WHOIS data is accurate and available. Every 12 hours an initial file is distributed to each resolution site. This file is a complete copy of all WHOIS data fields associated with each domain name under management. As interactions with the SRS cause the WHOIS data to be changed, these incremental changes are distributed to the resolution sites as an incremental file update. This incremental update occurs approximately every three minutes. When the new 12-hour full update is distributed, this file includes all past incremental updates. Verisign’s approach to frequency of synchronization between servers meets the Performance Specifications defined in Specification 10 of the Registry Agreement for new gTLDs.

26.2 Technical plan scope⁄scale consistent with the overall business approach and planned size of the registry
Verisign, MRH’s selected back-end registry services provider, is an experienced back-end registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.
Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .MERCK gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the ʺMost Likelyʺ scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the back-end registry services it provides to MRH fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response of this application.

26.3 Technical plan that is adequately resourced in the planned costs detailed in the financial section
Verisign, MRH’s selected back-end registry services provider, is an experienced back-end registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the ʺMost Likelyʺ scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the back-end registry services it provides to MRH fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response of this application.
Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .COM, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, of this application to support WHOIS services:
-Application Engineers: 19
-Database Engineers: 3
-Quality Assurance Engineers: 11
To implement and manage the .MERCK gTLD as described in this application, Verisign, MRH’s selected back-end registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .COM and .NET). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes startup learning curves and helps ensure that new staff members properly execute their duties.
26.4 Compliance with Relevant RFC
MRH’s selected back-end registry services provider’s (Verisign’s) WHOIS service complies with the data formats defined in Specification 4 of the Registry Agreement. Verisign will provision WHOIS services for registered domain names and associated data in the top-level domain (TLD). Verisign’s WHOIS services are accessible over Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), via both Transmission Control Protocol (TCP) port 43 and a Web-based directory service at whois.nic.MERCK, which, in accordance with RFC 3912, provides free public query-based access to domain name, registrar, and name server lookups. Verisign’s proposed WHOIS system meets all requirements as defined by ICANN for each registry under Verisign management. Evidence of this successful implementation, and thus compliance with the applicable RFCs, can be verified by a review of the .COM and .NET Registry Operator’s Monthly Reports that Verisign files with ICANN. These reports provide evidence of Verisign’s ability to meet registry operation service level agreements (SLAs) comparable to those detailed in Specification 10. The reports are accessible at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.
26.5 Compliance with Specifications 4 and 10 of Registry Agreement
In accordance with Specification 4, Verisign, MRH’s selected back-end registry services provider, provides a WHOIS service that is available via both port 43 in accordance with RFC 3912, and a Web-based directory service at whois.nic.MERCK also in accordance with RFC 3912, thereby providing free public query-based access. Verisign acknowledges that ICANN reserves the right to specify alternative formats and protocols, and upon such specification, Verisign will implement such alternative specification as soon as reasonably practicable.
The format of the following data fields conforms to the mappings specified in Extensible Provisioning Protocol (EPP) RFCs 5730 – 5734 so the display of this information (or values returned in WHOIS responses) can be uniformly processed and understood: domain name status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses, date, and times.
Specifications for data objects, bulk access, and lookups comply with Specification 4 and are detailed in the following subsections, provided in both bulk access and lookup modes.
Bulk Access Mode: This data is provided on a daily schedule to a party designated from time to time in writing by ICANN. The specification of the content and format of this data, and the procedures for providing access, shall be as stated below, until revised in the ICANN Registry Agreement.
The data is provided in three files:
-Domain Name File: For each domain name, the file provides the domain name, server name for each name server, registrar ID, and updated date.
-Name Server File: For each registered name server, the file provides the server name, each IP address, registrar ID, and updated date.
-Registrar File: For each registrar, the following data elements are provided: registrar ID, registrar address, registrar telephone number, registrar email address, WHOIS server, referral URL, updated date, and the name, telephone number, and email address of all the registrarʹs administrative, billing, and technical contacts.
Lookup Mode: Figures 26-4 through 26-6 provide the query and response format for domain name, registrar, and name server data objects.
See Figure 26-4
See Figure 26-5
See Figure 26-6
26.5.1 Specification 10, RDDS Registry Performance Specifications
The WHOIS service meets all registration data directory services (RDDS) registry performance specifications detailed in Specification 10, Section 2. Evidence of this performance can be verified by a review of the .COM and .NET Registry Operator’s Monthly Reports that Verisign files monthly with ICANN. These reports are accessible from the ICANN website at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.
In accordance with RDDS registry performance specifications detailed in Specification 10, Verisignʹs WHOIS service meets the following proven performance attributes:
-RDDS availability: GBP864 min of downtime (greater than98%)
-RDDS query RTT: GBP 2000 ms, for at least 95% of the queries
-RDDS update time: GBP 60 min, for at least 95% of the probes
26.6 Searchable WHOIS
Verisign, MRH’s selected back-end registry services provider, provides a searchable WHOIS service for the .MERCK gTLD. Verisign has experience in providing tiered access to WHOIS for the .NAME registry, and uses these methods and control structures to help reduce potential malicious use of the function. The searchable WHOIS system currently uses Apache’s Lucene full text search engine to index relevant WHOIS content with near-real time incremental updates from the provisioning system.
Features of the Verisign searchable WHOIS function include:
-Provision of a Web-based searchable directory service
-Ability to perform partial match, at least, for the following data fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state, or province)
-Ability to perform exact match, at least, on the following fields: registrar ID, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records)
-Ability to perform Boolean search supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT
-Search results that include domain names that match the selected search criteria

Verisign’s implementation of searchable WHOIS is EU Safe Harbor certified and includes appropriate access control measures that help ensure that only legitimate authorized users can use the service. Furthermore, Verisign’s compliance office monitors current ICANN policy and applicable privacy laws or policies to help ensure the solution is maintained within compliance of applicable regulations. Features of these access control measures include:
-All unauthenticated searches are returned as thin results
-Registry system authentication is used to grant access to appropriate users for thick WHOIS data search results.
-Account access is granted by the MRHʹs defined .MERCK gTLD admin user.
Potential Forms of Abuse and Related Risk Mitigation: Leveraging its experience providing tiered access to WHOIS for the .NAME registry and interacting with ICANN, data protection authorities, and applicable industry groups, Verisign, MRH’s selected back-end registry services provider, is knowledgeable of the likely data mining forms of abuse associated with a searchable WHOIS service. Figure 26-7 summarizes these potential forms of abuse and Verisign’s approach to mitigate the identified risk.
See Figure 26-7.

Q.27 – Registration Lifecycle

27.1 Complete Knowledge and Understanding of Registration Lifecycles and States

Starting with domain name registration and continuing through domain name delete operations, Merck Registry Holdings, Inc.’s selected backend registry services provider’s (Verisign’s) registry implements the full registration lifecycle for domain names supporting the operations in the Extensible Provisioning Protocol (EPP) specification. The registration lifecycle of the domain name starts with registration and traverses various states as specified in the following sections. The registry system provides options to update domain names with different server and client status codes that block operations based on the EPP specification. The system also provides different grace periods for different billable operations, where the price of the billable operation is credited back to the registrar if the billable operation is removed within the grace period. Together Figure 27 1 and Figure 27 2 define the registration states comprising the registration lifecycle and explain the trigger points that cause state-to-state transitions. States are represented as green rectangles within Figure 27 1.

See: Figure 27 1: Registration Lifecycle State Diagram

See: Figure 27 2: Registration States

27.1.1 Registration Lifecycle of Create⁄Update⁄Delete

The following section details the create⁄update⁄delete processes and the related renewal process that Verisign, Merck Registry Holdings, Inc.’s selected backend registry services provider, follows. For each process, this response defines the process function and its characterization, and as appropriate provides a process flow chart.

Create Process: The domain name lifecycle begins with a registration or what is referred to as a Domain Name Create operation in EPP. The system fully supports the EPP Domain Name Mapping as defined by RFC 5731, where the associated objects (e.g., hosts and contacts) are created independent of the domain name.

Process Characterization: The Domain Name Create command is received, validated, run through a set of business rules, persisted to the database, and committed in the database if all business rules pass. The domain name is included with the data flow to the DNS and WHOIS resolution services. If no name servers are supplied, the domain name is not included with the data flow to the DNS. A successfully created domain name has the created date and expiration date set in the database. Creates are subject to grace periods as described in Section 1.3 of this response, Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers.

The Domain Name Create operation is detailed in Figure 27 3 and requires the following attributes:

- A domain name that meets the string restrictions.
- A domain name that does not already exist.
- The registrar is authorized to create a domain name in .MERCK.
- The registrar has available credit.
- A valid Authorization Information (Auth-Info) value.
- Required contacts (e.g., registrant, administrative contact, technical contact, and billing contact) are specified and exist.
- The specified name servers (hosts) exist, and there is a maximum of 13 name servers.
- A period in units of years with a maximum value of 10 (default period is one year).

See: Figure 27 3: Create Process Flow Chart

Renewal Process: The domain name can be renewed unless it has any form of Pending Delete, Pending Transfer, or Renew Prohibited.

A request for renewal that sets the expiry date to more than ten years in the future is denied. The registrar must pass the current expiration date (without the timestamp) to support the idempotent features of EPP, where sending the same command a second time does not cause unexpected side effects.

Automatic renewal occurs when a domain name expires. On the expiration date, the registry extends the registration period one year and debits the registrar account balance. In the case of an auto-renewal of the domain name, a separate Auto-Renew grace period applies. Renewals are subject to grace periods as described in Section 1.3 of this response, Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers.

Process Characterization: The Domain Name Renew command is received, validated, authorized, and run through a set of business rules. The data is updated and committed in the database if it passes all business rules. The updated domain name’s expiration date is included in the flow to the WHOIS resolution service.

The Domain Name Renew operation is detailed in Figure 27 4 and requires the following attributes:

- A domain name that exists and is sponsored by the requesting registrar.
- The registrar is authorized to renew a domain name in .MERCK.
- The registrar has available credit.
- The passed current expiration date matches the domain name’s expiration date.
- A period in units of years with a maximum value of 10 (default period is one year). A domain name expiry past ten years is not allowed.

See: Figure 27 4: Renewal Process Flow Chart

Registrar Transfer Procedures. A registrant may transfer his⁄her domain name from his⁄her current registrar to another registrar. The database system allows a transfer as long as the transfer is not within the initial 60 days, per industry standard, of the original registration date.

The registrar transfer process goes through many process states, which are described in detail below, unless it has any form of Pending Delete, Pending Transfer, or Transfer Prohibited.

A transfer can only be initiated when the appropriate Auth-Info is supplied. The Auth-Info for transfer is only available to the current registrar. Any other registrar requesting to initiate a transfer on behalf of a registrant must obtain the Auth-Info from the registrant.

The Auth-Info is made available to the registrant upon request. The registrant is the only party other than the current registrar that has access to the Auth-Info. Registrar transfer entails a specified extension of the expiry date for the object. The registrar transfer is a billable operation and is charged identically to a renewal for the same extension of the period. This period can be from one to ten years, in one-year increments.

Because registrar transfer involves an extension of the registration period, the rules and policies applying to how the resulting expiry date is set after transfer are based on the renewal policies on extension.

Per industry standard, a domain name cannot be transferred to another registrar within the first 60 days after registration. This restriction continues to apply if the domain name is renewed during the first 60 days. Transfer of the domain name changes the sponsoring registrar of the domain name, and also changes the child hosts (ns1.sample.xyz) of the domain name (sample .xyz).

The domain name transfer consists of five separate operations:

- Transfer Request (Figure 27 5): Executed by a non-sponsoring registrar with the valid Auth-Info provided by the registrant. The Transfer Request holds funds of the requesting registrar but does not bill the registrar until the transfer is completed. The sponsoring registrar receives a Transfer Request poll message.
- Transfer Cancel (Figure 27 6): Executed by the requesting registrar to cancel the pending transfer. The held funds of the requesting registrar are reversed. The sponsoring registrar receives a Transfer Cancel poll message.
- Transfer Approve (Figure 27 7): Executed by the sponsoring registrar to approve the Transfer Request. The requesting registrar is billed for the Transfer Request and the sponsoring registrar is credited for an applicable Auto-Renew grace period. The requesting registrar receives a Transfer Approve poll message.
- Transfer Reject (Figure 27 8): Executed by the sponsoring registrar to reject the pending transfer. The held funds of the requesting registrar are reversed. The requesting registrar receives a Transfer Reject poll message.
- Transfer Query (Figure 27 9): Executed by either the requesting registrar or the sponsoring registrar of the last transfer.

The registry auto-approves a transfer if the sponsoring registrar takes no action. The requesting registrar is billed for the Transfer Request and the sponsoring registrar is credited for an applicable Auto-Renew grace period. The requesting registrar and the sponsoring registrar receive a Transfer Auto-Approve poll message.

See: Figure 27 5: Transfer Request Process
See: Figure 27 6: Transfer Cancel Process
See: Figure 27 7: Transfer Approve Process
See: Figure 27 8: Transfer Reject Process
See: Figure 27 9: Transfer Query Process

Delete Process: A registrar may choose to delete the domain name at any time.

Process Characterization: The domain name can be deleted, unless it has any form of Pending Delete, Pending Transfer, or Delete Prohibited.

A domain name is also prohibited from deletion if it has any in-zone child hosts that are name servers for domain names. For example, the domain name “sample.xyz” cannot be deleted if an in-zone host “ns.sample.xyz” exists and is a name server for “sample2.xyz.”

If the Domain Name Delete occurs within the Add grace period, the domain name is immediately deleted and the sponsoring registrar is credited for the Domain Name Create. If the Domain Name Delete occurs outside the Add grace period, it follows the Redemption grace period (RGP) lifecycle.

Update Process: The sponsoring registrar can update the following attributes of a domain name:

- Auth-Info
- Name servers
- Contacts (i.e., registrant, administrative contact, technical contact, and billing contact)
- Statuses (e.g., Client Delete Prohibited, Client Hold, Client Renew Prohibited, Client Transfer Prohibited, Client Update Prohibited)

Process Characterization: Updates are allowed provided that the update includes the removal of any Update Prohibited status. The Domain Name Update operation is detailed in Figure 27 10.

A domain name can be updated unless it has any form of Pending Delete, Pending Transfer, or Update Prohibited.

See: Figure 27 10: Update Process Flow Chart

27.1.2 Pending, Locked, Expired, and Transferred

Verisign, Merck Registry Holdings, Inc.’s selected backend registry services provider, handles pending, locked, expired, and transferred domain names as described here. When the domain name is deleted after the five-day Add grace period, it enters into the Pending Delete state. The registrant can return its domain name to active any time within the five-day Pending Delete grace period. After the five-day Pending Delete grace period expires, the domain name enters the Redemption Pending state and then is deleted by the system. The registrant can restore the domain name at any time during the Redemption Pending state.

When a non-sponsoring registrar initiates the domain name transfer request, the domain name enters Pending Transfer state and a notification is mailed to the sponsoring registrar for approvals. If the sponsoring registrar doesn’t respond within five days, the Pending Transfer expires and the transfer request is automatically approved.

EPP specifies both client (registrar) and server (registry) status codes that can be used to prevent registry changes that are not intended by the registrant. Currently, many registrars use the client status codes to protect against inadvertent modifications that would affect their customers’ high-profile or valuable domain names.

Verisign’s registry service supports the following client (registrar) and server (registry) status codes:

- clientHold
- clientRenewProhibited
- clientTransferProhibited
- clientUpdateProhibited
- clientDeleteProhibited
- serverHold
- serverRenewProhibited
- serverTransferProhibited
- serverUpdateProhibited
- serverDeleteProhibited

27.1.3 Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers

Verisign, Merck Registry Holdings, Inc.’s selected backend registry services provider, handles Add grace periods, Redemption grace periods, and notice periods for renewals or transfers as described here.

- Add Grace Period: The Add grace period is a specified number of days following the initial registration of the domain name. The current value of the Add grace period for all registrars is five days.
- Redemption Grace Period: If the domain name is deleted after the five-day grace period expires, it enters the Redemption grace period and then is deleted by the system. The registrant has an option to use the Restore Request command to restore the domain name within the Redemption grace period. In this scenario, the domain name goes to Pending Restore state if there is a Restore Request command within 30 days of the Redemption grace period. From the Pending Restore state, it goes either to the OK state, if there is a Restore Report Submission command within seven days of the Restore Request grace period, or a Redemption Period state if there is no Restore Report Submission command within seven days of the Restore Request grace period.
- Renew Grace Period: The Renew⁄Extend grace period is a specified number of days following the renewal⁄extension of the domain name’s registration period. The current value of the Renew⁄Extend grace period is five days.
- Auto-Renew Grace Period: All auto-renewed domain names have a grace period of 45 days.
- Transfer Grace Period: Domain names have a five-day Transfer grace period.

27.1.4 Aspects of the Registration Lifecycle Not Covered by Standard EPP RFCs

Merck Registry Holdings, Inc.’s selected backend registry services provider’s (Verisign’s) registration lifecycle processes and code implementations adhere to the standard EPP RFCs related to the registration lifecycle. By adhering to the RFCs, Verisign’s registration lifecycle is complete and addresses each registration-related task comprising the lifecycle. No aspect of Verisign’s registration lifecycle is not covered by one of the standard EPP RFCs and thus no additional definitions are provided in this response.

27.2 Consistency with any specific commitments made to registrants as adapted to the overall business approach for the proposed gTLD

The registration lifecycle described above applies to the .MERCK gTLD as well as other TLDs managed by Verisign, Merck Registry Holdings, Inc.’s selected backend registry services provider; thus Verisign remains consistent with commitments made to its registrants. No unique or specific registration lifecycle modifications or adaptations are required to support the overall business approach for the .MERCK gTLD.

To accommodate a range of registries, Verisign’s registry implementation is capable of offering both a thin and thick WHOIS implementation, which is also built upon Verisign’s award-winning ATLAS infrastructure.

27.3 Compliance with relevant RFCS

Merck Registry Holdings, Inc.’s selected backend registry services provider’s (Verisign’s) registration lifecycle complies with applicable RFCs, specifically RFCs 5730 – 5734 and 3915. The system fully supports the EPP Domain Name Mapping as defined by RFC 5731, where the associated objects (e.g., hosts and contacts) are created independent of the domain name.

In addition, in accordance with RFCs 5732 and 5733, the Verisign registration system enforces the following domain name registration constraints:

- Uniqueness⁄Multiplicity: A second-level domain name is unique in the .MERCK database. Two identical second-level domain names cannot simultaneously exist in .MERCK. Further, a second-level domain name cannot be created if it conflicts with a reserved domain name.
- Point of Contact Associations: The domain name is associated with the following points of contact. Contacts are created and managed independently according to RFC 5733.
-- Registrant
-- Administrative contact
-- Technical contact
-- Billing contact
- Domain Name Associations: Each domain name is associated with:
-- A maximum of 13 hosts, which are created and managed independently according to RFC 5732
-- An Auth-Info, which is used to authorize certain operations on the object
-- Status(es), which are used to describe the domain name’s status in the registry
-- A created date, updated date, and expiry date

27.4 Demonstrates that technical resources required to carry through the plans for this element are already on hand or readily available

Verisign, Merck Registry Holdings, Inc.’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Merck Registry Holdings, Inc. fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .COM, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support the registration lifecycle:

- Application Engineers: 19
- Customer Support Personnel: 36
- Database Administrators: 8
- Database Engineers: 3
- Quality Assurance Engineers: 11
- SRS System Administrators: 13

To implement and manage the .MERCK gTLD as described in this application, Verisign, Merck Registry Holdings, Inc.’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .COM and .NET). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-

Q.28 – Abuse Prevention and Mitigation

28.1 Abuse Prevention and Mitigation Implementation Plan

Merck Registry Holdings, Inc.’s (“MRH”) primary safeguard against mitigating abusive and⁄or non-compliant registrations within the .MERCK name space is the limited universe of registrants that will be permitted to register with the .MERCK gTLD. As a branded gTLD registry, registration will be limited to qualified subsidiaries and affiliates of Merck, Merck foundations and related parties, and approved licensees. This built-in validation mechanism promotes uniform compliance and increase accuracy of WHOIS data. MRH is committed to providing best in class safeguards and will be closely monitoring other .BRAND applicants for suitable safeguards.

28.1.2 Policies for Handling Complaints Regarding Abuse

As required by the ICANN template Registry Agreement, MRH will establish, publish, and maintain on its website a single point of contact for handling abuse complaints. This contact will be a role account, e.g., abuse@registry.merck. All email inquiries submitted to this email account will be responded to in a reasonably timely manner. MRH will employ an escalated complaint procedure. This procedure will place priority on complaints received from a trusted⁄verified source (e.g. law enforcement). If the complaint falls within the scope of MRH’s Abuse Policy Listed below, MRH reserves the right to suspend or cancel the non-compliant domain.

The role email account identified above will have multiple MRH staff recipients to allow for monitoring on a 24X7 basis. In addition the phone number provided for on the Registry website will be answered by MRH staff during normal working hours.

MRH has not yet finalized an Acceptable Use Policy. A draft policy has been included below but has not yet been finalized by Merck’s legal team. Such approval and posting of the policy will be done in advance of the launch of the registry.

28.1.3 Proposed Measures for Removal of Orphan Glue Records

Although orphan glue records often support correct and ordinary operation of the Domain Name System (DNS), registry operators will be required to remove orphan glue records (as defined at http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf) when provided with evidence in written form that such records are present in connection with malicious conduct. MRH’s selected back-end registry services provider’s (Verisign’s) registration system is specifically designed to not allow orphan glue records. Registrars are required to delete⁄move all dependent DNS records before they are allowed to delete the parent domain.
To prevent orphan glue records, Verisign performs the following checks before removing a domain or name server:

Checks during domain delete:
- Parent domain delete is not allowed if any other domain in the zone refers to the child name server.
- If the parent domain is the only domain using the child name server, then both the domain and the glue record are removed from the zone.

Check during explicit name server delete:
Verisign confirms that the current name server is not referenced by any domain name (in-zone) before deleting the name server.
Zone-file impact:
If the parent domain references the child name server AND if other domains in the zone also reference it AND if the parent domain name is assigned a serverHold status, then the parent domain goes out of the zone but the name server glue record does not.
If no domains reference a name server, then the zone file removes the glue record.
28.1.4 Resourcing Plans

Details related to resourcing plans for the initial implementation and ongoing maintenance of MRH’s abuse plan are provided in Section 2 of this response.

28.1.5 Measures to Promote WHOIS Accuracy

Ensuring the accuracy of WHOIS information is of paramount importance to MRH in the operation of the .MERCK gTLD. MRH will employ the following mechanism to promote WHOIS accuracy.

-Registration will be limited to:
(a) Qualified subsidiaries and affiliates
(b) Merck foundations and related parties
(c) Approved licensees
-There will be a strict prohibition against the use of proxy registration services;
-MRH will maintain a web-based form for third parties to submit claims regarding false and or inaccurate WHOIS data.

28.1.5.1 Authentication of Registrant Information

Because all registrants in the .MERCK gTLD namespace will have a pre-existing relationship with Merck & Co. Inc., parent of Merck Sharp and Dohme Corp, Whitehouse Station, New Jersey, USA (collectively “Merck”),, this will be pre-authenticated thus promoting accurate and complete WHOIS data.

28.1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness

Verisign, MRH’s selected back-end registry services provider, has established policies and procedures to encourage registrar compliance with ICANN’s WHOIS accuracy requirements. Verisign provides the following service to MRH for incorporation into its full-service registry operations.

WHOIS data reminder process. Verisign regularly reminds registrars of their obligation to comply with ICANN’s WHOIS Data Reminder Policy, which was adopted by ICANN as a consensus policy on 27 March 2003 (http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm). Verisign sends a notice to all registrars once a year reminding them of their obligation to be diligent in validating the WHOIS information provided during the registration process, to investigate claims of fraudulent WHOIS information, and to cancel domain name registrations for which WHOIS information is determined to be invalid.

28.1.5.3 Use of Registrars

MRH has not yet made any determinations regarding which registrar will be selected to provide domain name registration services in the gTLD. Merck currently uses one corporate domain name registrar. The likely registrar plan will be to use one corporate registrar. However, any final determination will depend upon MRH and the registrar of choice reaching an agreed-upon price for the specified services.

Registrar services will be provided by certain ICANN-accredited registrars that enter into a Registrar-Registry Agreement (RRA) with MRH, the Registry Operator.

28.1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements for Resolution

MRH will have an Authorized Usage Policy that will govern how a registrant may use its registered domain name(s). A draft framework of this policy is as follows:

By registering a name in this gTLD, the registrant agrees to be bound by the terms of this Acceptable Use Policy (AUP). Registrant may not:
1. Use domain names for any purposes that are prohibited by the laws of the jurisdiction(s) in which registrant does business, or any other applicable law.
2. Use domain names for any purposes or in any manner that violates a statute, rule, or law governing use of the Internet and⁄or electronic commerce (specifically including “phishing,” ʺpharming,ʺ distributing Internet viruses and other destructive activities).
3. Use domain names for the following types of activity:
i. Violation of the privacy or publicity rights of any third party,
ii. Promotion of or engagement in hate speech; hate crime; terrorism; violence against people, animals, or property; or intolerance of or against any protected class;
iii. Promotion of or engagement in defamatory, harassing, abusive or otherwise objectionable behavior;
iv. Promotion of or engagement in child pornography or the exploitation of children;
v. Promotion of or engagement in any spam or other unsolicited bulk email, or computer or network hacking or cracking;
vi. Infringement on the intellectual property rights of another member of the .MERCK gTLD community, or any other person or entity;
vii. Engagement in activities designed to impersonate any third party or create a likelihood of confusion in sponsorship;
viii. Interference with the operation of the .MERCK gTLD or services offered by MRH;
ix. Installation of any viruses, worms, bugs, Trojan horses, or other code, files, or programs designed to, or capable of, disrupting, damaging, or limiting the functionality of any software or hardware; or distributing false or deceptive language, or unsubstantiated or comparative claims, regarding MRH;
x. Registration of .MERCK domain names for the purpose of reselling or transferring those domain names.

28.1.7 Controls to Ensure Proper Access to Domain Functions

MRH will primarily be relying upon the safeguards incorporated at the registrar level to ensure proper access to domain names. Because MRH envisions working with a single corporate registrar, this will provide an important gate keeping functions.
Furthermore, Only qualified subsidiaries and affiliates of Merck, approved licensees, and Merck foundations and related parties will be eligible for inclusion and registration in the community based .MERCK gTLD.

28.1.7.2 Requiring Multiple, Unique Points of Contact and Means of Notification

MRH will likely assigned multiple unique point of contact. In connection with compliance, abuse, or malicious activity, an individual within MRH’s legal department will be identified. In connection with technical, security, and⁄or stability issues, an individual in MRH’s IT department will be identified. These unique POCs will have a corresponding unique email address that will auto-forward emails to these addresses to multiple individuals in each of the appropriate departments to ensure that there is no single point of failure in the communication chain.

28.2 Technical plan that is adequately resourced in the planned costs detailed in the financial section

28.2.1 Resource Planning

MRH is committed to operating the .MERCK gTLD in a manner that protects the core brand of MRH. MRH has projected that a staff level 0.25 Resource Year (“RY”) (0.5 RY total per GTLD for both legal and IT staff) for legal compliance and oversight for the gTLD. In addition, MRH can rely upon existing in-house legal and other support staff should the need arise. MRH has strategically chosen Verisign as its registry services provider because of their excellent track record in operating some of the worldʹs most complex and critical top level domains. Verisignʹs support for the .MERCK gTLD will help ensure its success.

28.2.2 Resource Planning Specific to Back-end Registry Activities

Verisign, MRH’s selected back-end registry services provider, is an experienced back-end registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a gTLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the back-end registry services it provides to MRH fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .COM, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support abuse prevention and mitigation:
Application Engineers: 19
Business Continuity Personnel: 3
Customer Affairs Organization: 9
Customer Support Personnel: 36
Information Security Engineers: 11
Network Administrators: 11
Network Architects: 4
Network Operations Center (NOC) Engineers: 33
Project Managers: 25
Quality Assurance Engineers: 11
Systems Architects: 9

To implement and manage the .MERCK gTLD as described in this application, Verisign, MRH’s selected back-end registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .COM and .NET). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.

28.3.2 Ongoing Anti-Abuse Policies and Procedures

28.3.2.1 Policies and Procedures that Identify Malicious or Abusive Behavior

Verisign, MRH’s selected back-end registry services provider, provides the following service to MRH for incorporation into its full-service registry operations.
Malware scanning service. Registrants are often unknowing victims of malware exploits. Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in their domain names.

Verisign’s malware scanning service helps prevent websites from infecting other websites by scanning web pages for embedded malicious content that will infect visitors’ websites. Verisign’s malware scanning technology uses a combination of in-depth malware behavioral analysis, anti-virus results, detailed malware patterns, and network analysis to discover known exploits for the particular scanned zone. If malware is detected, the service sends the registrar a report that contains the number of malicious domains found and details about malicious content within its TLD zones. Reports with remediation instructions are provided to help registrars and registrants eliminate the identified malware from the registrant’s website.

28.3.2.2 Policies and Procedures that Address the Abusive Use of Registered Names

Suspension processes: Any registrant which ceases to have a qualified ongoing legal relationship with MRH will immediately have their domain name suspended and⁄or cancelled. In addition, any registrant that fails to timely respond to a WHOIS accuracy complaint is subject to having their domain name suspended and⁄or cancelled. Prior to taking any affirmation action in connection with an WHOIS accuracy compliant, MRH will attempt to contact registrant through various electronic means (email, telephone and fax).
Suspension processes conducted by back-end registry services provider: In the case of domain name abuse, MRH will determine whether to take down the subject domain name. Verisign, MRH’s selected back-end registry services provider, will follow the following auditable processes to comply with the suspension request.
Verisign Suspension Notification: MRH submits the suspension request to Verisign for processing, documented by:
Threat domain name
Registry incident number
Incident narrative, threat analytics, screen shots to depict abuse, and⁄or other evidence
Threat classification
Threat urgency description
Recommended timeframe for suspension⁄takedown
Technical details (e.g., WHOIS records, IP addresses, hash values, anti-virus detection results⁄nomenclature, name servers, domain name statuses that are relevant to the suspension)
Incident response, including surge capacity

Verisign Notification Verification: When Verisign receives a suspension request from MRH, it performs the following verification procedures:
Validate that all the required data appears in the notification.
Validate that the request for suspension is for a registered domain name.
Return a case number for tracking purposes.

Suspension Rejection: If required data is missing from the suspension request, or the domain name is not registered, the request will be rejected and returned to MRH with the following information:
Threat domain name
Registry incident number
Verisign case number
Error reason

Upon MRH request, Verisign can provide a process for registrants to protest the suspension.
Domain Suspension: Verisign places the domain to be suspended on the following statuses:
serverUpdateProhibited
serverDeleteProhibited
serverTransferProhibited
serverHold

Suspension Acknowledgement: Verisign notifies MRH that the suspension has been completed. Acknowledgement of the suspension includes the following information:
Threat domain name
Registry incident number
Verisign case number
Case number
Domain name
MRH abuse contact name and number, or registrar abuse contact name and number
Suspension status

28.4 When executed in accordance with the Registry Agreement, plans will result in compliance with contractual requirements

As noted in the Question 18 business plan, the purpose of this gTLD registry is to provide MRH with a secure and trusted namespace that is the representation of its brand online. MRH intends to fully comply with the contractual requirements of the Registrant Agreement. Moreover, MRH has a vested interest to ensure that all qualified subsidiaries, affiliates, approved licensees, Merck foundations and other related parties adhere to these legal requirements.

As noted, in the above referenced compliance section, failure for registrants to timely remedy any non-compliant activity will result in the suspension and⁄or deletion of the domain in question.

28.5 Technical plan scope⁄scale that is consistent with the overall business approach and planned size of the registry

28.5.1 Scope⁄Scale Consistency

As a branded gTLD Registry, the allocated registry staff will ensure that all registrations are in compliance with the requirements set forth in the Registrant Agreement. As this staff member(s) is proposed to be sourced from MRH’s legal department, this will facilitate compliance of affiliates, subsidiaries, licensees, Merck foundations and related parties with whom Merck has a pre-existing legal relationship. Unlike other registries that must oversee numerous registrars and untold number of registrants, the .MERCK gTLD will be a limited-universe of known entities with a pre-existing relationship with the Merck that will likely be registered through one registrar.

28.5.2 Scope⁄Scale Consistency Specific to Back-End Registry Activities

Verisign, MRH’s selected back-end registry services provider, is an experienced back-end registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.
Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .MERCK gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the back-end registry services it provides to MRH fully accounts for cost related to this infrastructure, which is provided as “Other Operating Cost” (Template 1, Line I.L) within the Question 46 financial projections response.

VeriSign, Inc. Response to Question 29 Rights Protection Mechanisms

29.1 Mechanisms Designed to Prevent Abusive Registrations

Rights protection is a core objective of Merck Registry Holdings, Inc. (“MRH”). MRH will implement and adhere to any rights protection mechanisms (RPMs) that may be mandated from time to time by ICANN, including each mandatory RPM set forth in the Trademark Clearinghouse model contained in the Registry Agreement, specifically Specification 7. MRH acknowledges that, at a minimum, ICANN requires a Sunrise period, a Trademark Claims period, and interaction with the Trademark Clearinghouse with respect to the registration of domain names for the .MERCK gTLD. It should be noted that because ICANN, as of the time of this application submission, has not issued final guidance with respect to the Trademark Clearinghouse, MRH cannot fully detail the specific implementation of the Trademark Clearinghouse within this application. MRH will adhere to all processes and procedures to comply with ICANN guidance once this guidance is finalized.

As described in this response, MRH will implement a Sunrise period and Trademark Claims service with respect to the registration of domain names within the .MERCK gTLD. Certain aspects of the Sunrise period and⁄or Trademark Claims service may be administered on behalf of MRH by MRH-approved registrars or by subcontractors of MRH, such as its selected back-end registry services provider, Verisign.

At the time of filing, ICANN has not yet released final details on the Trademark Clearinghouse service. However, the protection of intellectual property is of paramount importance to MRH. Given this and the fact that the initial proposed use of the registry is for the exclusive use of qualified subsidiaries and affiliates of Merck, Merck foundations and related parties, and approved licensees, all initial domain name registrations in the .MERCK namespace will be made by Merck and the aforementioned parties. Therefore, while MRH will implement a Sunrise period and Trademark Claims process, depending upon the cost to access the Trademark Clearinghouse, MRH may elect to forego the minimum one-month Sunrise period and register names in the gTLD following this mandatory period.

Sunrise Period: As provided by the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook, the Sunrise service pre-registration procedure for domain names continues for at least 30 days prior to the launch of the general registration of domain names in the gTLD (unless MRH decides to offer a longer Sunrise period).

During the Sunrise period, holders of marks that have been previously validated by the Trademark Clearinghouse receive notice of domain names that are an identical match (as defined in the ICANN Applicant Guidebook) to their mark(s). Such notice is in accordance with ICANN’s requirements and is provided by MRH either directly or through MRH-approved registrars.

MRH requires all registrants, either directly or through MRH-approved registrars, to i) affirm that said registrants meet the Sunrise Eligibility Requirements (SER), and ii) submit to the Sunrise Dispute Resolution Policy (SDRP) consistent with Section 6 of the Trademark Clearinghouse model. At a minimum MRH recognizes and honors all word marks for which a proof of use was submitted and validated by the Trademark Clearinghouse as well as any additional eligibility requirements as specified in Question 18.

During the Sunrise period, MRH and⁄or MRH-approved registrars, as applicable, are responsible for determining whether each domain name is eligible to be registered (including in accordance with the SERs).

Trademark Claims Service: As provided by the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook, all new gTLDs will have to provide a Trademark Claims service for a minimum of 60 days after the launch of the general registration of domain names in the gTLD (Trademark Claims period).

During the Trademark Claims period, in accordance with ICANN’s requirements, MRH or the MRH-approved registrar will send a Trademark Claims Notice to any prospective registrant of a domain name that is an identical match (as defined in the ICANN Applicant Guidebook) to any mark that is validated in the Trademark Clearinghouse. The Trademark Claims Notice will include links to the Trademark Claims as listed in the Trademark Clearinghouse and will be provided at no cost.

Prior to registration of said domain name, MRH or the MRH-approved registrar will require each prospective registrant to provide the warranties dictated in the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook. Those warranties will include receipt and understanding of the Trademark Claims Notice and confirmation that registration and use of said domain name will not infringe on the trademark rights of the mark holders listed. Without receipt of said warranties, the MRH or the MRH-approved registrar will not process the domain name registration.

Following the registration of a domain name, the MRH-approved registrar will provide a notice of domain name registration to the holders of marks that have been previously validated by the Trademark Clearinghouse and are an identical match. This notice will be as dictated by ICANN. At a minimum MRH will recognize and honor all word marks validated by the Trademark Clearinghouse.

29.2 Mechanisms Designed to Identify and address the abusive use of registered names on an ongoing basis

In addition to the Sunrise and Trademark Claims services described in Section 1 of this response, MRH implements and adheres to RPMs post-launch as mandated by ICANN, and confirms that registrars accredited for the .MERCK gTLD are in compliance with these mechanisms. Certain aspects of these post-launch RPMs may be administered on behalf of MRH by MRH-approved registrars or by subcontractors of MRH, such as its selected back-end registry services provider, Verisign.

These post-launch RPMs include the established Uniform Domain-Name Dispute-Resolution Policy (UDRP), as well as the newer Uniform Rapid Suspension System (URS) and Trademark Post-Delegation Dispute Resolution Procedure (PDDRP). Where applicable, MRH will implement all determinations and decisions issued under the corresponding RPM.

After a domain name is registered, trademark holders can object to the registration through the UDRP or URS. Objections to the operation of the gTLD can be made through the PDDRP.

The following descriptions provide implementation details of each post-launch RPM for the .MERCK gTLD:

- UDRP: The UDRP provides a mechanism for complainants to object to domain name registrations. The complainant files its objection with a UDRP provider and the domain name registrant has an opportunity to respond. The UDRP provider makes a decision based on the papers filed. If the complainant is successful, ownership of the domain name registration is transferred to the complainant. If the complainant is not successful, ownership of the domain name remains with the domain name registrant. MRH and entities operating on its behalf adhere to all decisions rendered by UDRP providers.
- URS: As provided in the Applicant Guidebook, all registries are required to implement the URS. Similar to the UDRP, a complainant files its objection with a URS provider. The URS provider conducts an administrative review for compliance with filing requirements. If the complaint passes review, the URS provider notifies the registry operator and locks the domain. A lock means that the registry restricts all changes to the registration data, but the name will continue to resolve. After the domain is locked, the complaint is served to the domain name registrant, who has an opportunity to respond. If the complainant is successful, the registry operator is informed and the domain name is suspended for the balance of the registration period; the domain name will not resolve to the original website, but to an informational web page provided by the URS provider. If the complainant is not successful, the URS is terminated and full control of the domain name registration is returned to the domain name registrant. Similar to the existing UDRP, MRH and entities operating on its behalf adhere to decisions rendered by the URS providers.
- PDDRP: As provided in the Applicant Guidebook, all registries are required to implement the PDDRP. The PDDRP provides a mechanism for a complainant to object to the registry operator’s manner of operation or use of the gTLD. The complainant files its objection with a PDDRP provider, who performs a threshold review. The registry operator has the opportunity to respond and the provider issues its determination based on the papers filed, although there may be opportunity for further discovery and a hearing. MRH participates in the PDDRP process as specified in the Applicant Guidebook.

Additional Measures Specific to Rights Protection: MRH provides additional measures against potentially abusive registrations. These measures help mitigate phishing, pharming, and other Internet security threats. The measures exceed the minimum requirements for RPMs defined by Specification 7 of the Registry Agreement and are available at the time of registration. These measures include:

- Rapid Takedown or Suspension Based on Court Orders: MRH complies promptly with any order from a court of competent jurisdiction that directs it to take any action on a domain name that is within its technical capabilities as a gTLD registry. These orders may be issued when abusive content, such as child pornography, counterfeit goods, or illegal pharmaceuticals, is associated with the domain name.
- Anti-Abuse Process: MRH implements an anti-abuse process that is executed based on the type of domain name takedown requested. The anti-abuse process is for malicious exploitation of the DNS infrastructure, such as phishing, botnets, and malware.
- Authentication Procedures: Verisign, MRH’s selected back-end registry services provider, uses two-factor authentication to augment security protocols for telephone, email, and chat communications.
-Eligibility Requirements: As discussed above, the proposed use of the registry is for the exclusive use of qualified subsidiaries and affiliates of Merck, Merck foundations and related parties, and approved licensees. Thus, all domain name registrations in the .MERCK namespace will be made by these aforementioned parties. This is expected to significantly reduce and⁄or eliminate the chance of any abusive registrations.

29.3 Resourcing Plans

29.3.1 Resource Planning

MRH has included in its business plan staffing sufficient to implement and oversee the aforementioned Rights Protection Mechanism procedures. As previously noted in the application, this staffing resource will most likely be sourced from within MRH’s legal department. Should additional subject matter expertise be required, MRH may engage the services of outside specialists on an as-needed basis.

29.3.2 Resource Planning Specific to Back-End Registry Activities

Verisign, MRH’s selected back-end registry services provider, is an experienced back-end registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a gTLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for the .MERCK gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the back-end registry services it provides to MRH fully accounts for cost related to this infrastructure, which is provided as Line IIb.G, Total Critical Registry Function Cash Outflows, within the Question 46 financial projections response of this application.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .COM, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support the implementation of RPMs:
- Customer Affairs Organization: 9
- Customer Support Personnel: 36
- Information Security Engineers: 11

To implement and manage the .MERCK gTLD as described in this application, Verisign, MRH’s selected back-end registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed .MERCK gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .COM and .NET). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.

Q.30A – Security Policy

30A.1 Detailed description of processes and solutions deployed to manage logical security across infrastructure and systems, monitoring and detecting threats and security vulnerabilities and taking appropriate steps to resolve them

Merck Registry Holdings, Inc.’s selected back-end registry services provider’s Verisign, Inc. (“Verisign”)’s comprehensive security policy has evolved over the years as part of managing some of the world’s most critical TLDs. Verisign’s Information Security Policy is the primary guideline that sets the baseline for all other policies, procedures, and standards that Verisign follows. This security policy addresses all of the critical components for the management of back-end registry services, including architecture, engineering, and operations.

Verisign’s general security policies and standards with respect to these areas are provided as follows:

Architecture
- Information Security Architecture Standard: This standard establishes the Verisign standard for application and network architecture. The document explains the methods for segmenting application tiers, using authentication mechanisms, and implementing application functions.
- Information Security Secure Linux Standard: This standard establishes the information security requirements for all systems that run Linux throughout the Verisign organization.
- Information Security Secure Oracle Standard: This standard establishes the information security requirements for all systems that run Oracle throughout the Verisign organization.
- Information Security Remote Access Standard: This standard establishes the information security requirements for remote access to terminal services throughout the Verisign organization.
- Information Security SSH Standard: This standard establishes the information security requirements for the application of Secure Shell (SSH) on all systems throughout the Verisign organization.

Engineering
- Secure SSL⁄TLS Configuration Standard: This standard establishes the information security requirements for the configuration of Secure Sockets Layer⁄Transport Layer Security (SSL⁄TLS) for all systems throughout the Verisign organization.
- Information Security C++ Standards: These standards explain how to use and implement the functions and application programming interfaces (APIs) within C++. The document also describes how to perform logging, authentication, and database connectivity.
- Information Security Java Standards: These standards explain how to use and implement the functions and APIs within Java. The document also describes how to perform logging, authentication, and database connectivity.

Operations
- Information Security DNS Standard: This standard establishes the information security requirements for all systems that run DNS systems throughout the Verisign organization.
- Information Security Cryptographic Key Management Standard: This standard provides detailed information on both technology and processes for the use of encryption on Verisign information security systems.
- Secure Apache Standard: Verisign has a multitude of Apache web servers, which are used in both production and development environments on the Verisign intranet and on the Internet. They provide a centralized, dynamic, and extensible interface to various other systems that deliver information to the end user. Because of their exposure and the confidential nature of the data that these systems host, adequate security measures must be in place. The Secure Apache Standard establishes the information security requirements for all systems that run Apache web servers throughout the Verisign organization.
- Secure Sendmail Standard: Verisign uses sendmail servers in both the production and development environments on the Verisign intranet and on the Internet. Sendmail allows users to communicate with one another via email. The Secure Sendmail Standard establishes the information security requirements for all systems that run sendmail servers throughout the Verisign organization.
- Secure Logging Standard: This standard establishes the information security logging requirements for all systems and applications throughout the Verisign organization. Where specific standards documents have been created for operating systems or applications, the logging standards have been detailed. This document covers all technologies.
- Patch Management Standard: This standard establishes the information security patch and upgrade management requirements for all systems and applications throughout Verisign.

General
- Secure Password Standard: Because passwords are the most popular and, in many cases, the sole mechanism for authenticating a user to a system, great care must be taken to help ensure that passwords are “strong” and secure. The Secure Password Standard details requirements for the use and implementation of passwords.
- Secure Anti-Virus Standard: Verisign must be protected continuously from computer viruses and other forms of malicious code. These threats can cause significant damage to the overall operation and security of the Verisign network. The Secure Anti-Virus Standard describes the requirements for minimizing the occurrence and impact of these incidents.

Security processes and solutions for the .MERCK gTLD are based on the standards defined above, each of which is derived from Verisign’s experience and industry best practice. These standards comprise the framework for the overall security solution and applicable processes implemented across all products under Verisign’s management. The security solution and applicable processes include, but are not limited to:
- System and network access control (e.g., monitoring, logging, and backup)
- Independent assessment and periodic independent assessment reports
- Denial of service (DoS) and distributed denial of service (DDoS) attack mitigation
- Computer and network incident response policies, plans, and processes
- Minimization of risk of unauthorized access to systems or tampering with registry data
- Intrusion detection mechanisms, threat analysis, defenses, and updates
- Auditing of network access
- Physical security

Further details of these processes and solutions are provided in Part B of this response.

30A.1.1 Security Policy and Procedures for the Proposed Registry

Specific security policy related details, requested as the bulleted items of Question 30 – Part A, are provided here.

Independent Assessment and Periodic Independent Assessment Reports.
To help ensure effective security controls are in place, Merck Registry Holdings, Inc., through its selected back-end registry services provider, Verisign, conducts a yearly American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) SAS 70 audit on all of its data centers, hosted systems, and applications. During these SAS 70 audits, security controls at the operational, technical, and human level are rigorously tested. These audits are conducted by a certified and accredited third party and help ensure that Verisign’s in-place environments meet the security criteria specified in Verisign’s customer contractual agreements and are in accordance with commercially accepted security controls and practices. Verisign also performs numerous audits throughout the year to verify its security processes and activities. These audits cover many different environments and technologies and validate Verisign’s capability to protect its registry and DNS resolution environments. Figure 30A-1 lists a subset of the audits that Verisign conducts. For each audit program or certification listed in Figure 30A-1, Verisign has included, as attachments to the Part B component of this response, copies of the assessment reports conducted by the listed third-party auditor. From Verisign’s experience operating registries, it has determined that together these audit programs and certifications provide a reliable means to ensure effective security controls are in place and that these controls are sufficient to meet ICANN security requirements and therefore are commensurate with the guidelines defined by ISO 27001.

(See: Figure 30A-1: Verisign Independent Assessment Activities)

Augmented Security Levels or Capabilities: See Section 5 of this response.

Commitments Made to Registrants Concerning Security Levels: See Section 4 of this response.

30A.2 Security capabilities are consistent with the overall business approach and planned size of the registry

Merck Registry Holdings, Inc. does not foresee the need for any enhanced security mechanisms beyond those currently provided by Verisign based upon the following factors; existing Merck Registry Holdings, Inc. IT security protocols; the restrictive nature of the .MERCK registrant universe; validation procedures that Merck Registry Holdings, Inc. will be undertaking prior to allocating names in the gTLD; security features imposed at the registrar level; and, the limited number of registrars (likely a single registrar) that will be connecting to the registry.

Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, is an experienced back-end registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.

Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .MERCK gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the back-end registry services it provides to Merck Registry Holdings, Inc. fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

30A.3 Technical plan adequately resourced in the planned costs detailed in the financial section

30A.3.1 Resource Planning

It is anticipated that Merck Registry Holdings, Inc.’s existing IT personnel will provide security support services, as necessary, to operate the .MERCK registry. In addition, Merck Registry Holdings, Inc. will engage the services of subject matter experts to provide consulting services on any DNS-specific matters that may be outside the skill set of its internal IT staff.

30A.3.2 Resource Planning Specific to Back-End Registry Activities

Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, is an experienced back-end registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a gTLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the back-end registry services it provides to Merck Registry Holdings, Inc. fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .COM, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel role, which is described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support its security policy:
Information Security Engineers: 11

To implement and manage the .MERCK gTLD as described in this application, Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .COM and .NET). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes startup learning curves and helps ensure that new staff members properly execute their duties.

30A.4 Security measures are consistent with any commitments made to registrants regarding security levels

Verisign is Merck Registry Holdings, Inc.’s selected back-end registry services provider. For the .MERCK gTLD, no unique security measures or commitments must be made by Verisign or Merck Registry Holdings, Inc. to any registrant.

30A.5 Security measures are appropriate for the applied-for gTLD string

No unique security measures are necessary to implement the .MERCK gTLD. As defined in Section 1 of this response, Verisign, Merck Registry Holdings, Inc.’s selected back-end registry services provider, commits to providing back-end registry services in accordance with the following international and relevant security standards:
- American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) SAS 70
- WebTrust⁄SysTrust for Certification Authorities (CA)

Merck Registry Holdings, Inc. does not foresee the need for any enhanced security mechanisms beyond those currently provided by Verisign based upon the following factors; existing Merck Registry Holdings, Inc. IT security protocols; the restrictive nature of the .MERCK registrant universe; validation procedures that Merck Registry Holdings, Inc. will be undertaking prior to allocating names in the gTLD; security features imposed at the registrar level; and, the limited number of registrars (likely a single registrar) that will be connecting to the registry.

© Internet Corporation For Assigned Names and Numbers.