ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Merck KGaA

String: merck

Originally Posted: 13 June 2012

Application ID: 1-980-7217


Applicant Information


1. Full legal name

Merck KGaA

2. Address of the principal place of business

Frankfurter Strasse 250
Darmstadt 64293
DE

3. Phone number

+496151720

4. Fax number

+496151722000

5. If applicable, website or URL

http:⁄⁄www.merckgroup.com

Primary Contact


6(a). Name

Mr. Torsten Bettinger

6(b). Title

Partner

6(c). Address


6(d). Phone Number

+49 89988275

6(e). Fax Number


6(f). Email Address

bettinger@bettinger.de

Secondary Contact


7(a). Name

Mr. Michael Schramm

7(b). Title

Partner

7(c). Address


7(d). Phone Number

+49 8999209103

7(e). Fax Number


7(f). Email Address

schramm@bettinger.de

Proof of Legal Establishment


8(a). Legal form of the Applicant

Corporation with general partners (in German: ʺKommanditgesellschaft auf Aktienʺ, abbreviated KGaA)

8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).

German Law

8(c). Attach evidence of the applicant's establishment.

Attachments are not displayed on this form.

9(a). If applying company is publicly traded, provide the exchange and symbol.

Frankfurt_Stock_Exchange;MRK

9(b). If the applying entity is a subsidiary, provide the parent company.


9(c). If the applying entity is a joint venture, list all joint venture partners.


Applicant Background


11(a). Name(s) and position(s) of all directors

Dr. Bernd ReckmannMember of the Board
Dr. Kai BeckmannMember of the Board
Dr. Karl Ludwig KleyChairman of the Board
Dr. Stefan OschmannMember of the Board
Matthias ZachertMember of the Board

11(b). Name(s) and position(s) of all officers and partners

Dr. Bernd ReckmannHead of Chemicals Business Sector
Dr. Kai BeckmannHead of Human Resources
Dr. Karl Ludwig KleyChief Executive Officer
Dr. Stefan OschmannHead of the Pharmaceuticals Business Sector
Matthias ZachertChief Financial Officer

11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares

E. Merck KGNot Applicable

11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility


Applied-for gTLD string


13. Provide the applied-for gTLD string. If an IDN, provide the U-label.

merck

14(a). If an IDN, provide the A-label (beginning with "xn--").


14(b). If an IDN, provide the meaning or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.


14(c). If an IDN, provide the language of the label (in English).


14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).


14(d). If an IDN, provide the script of the label (in English).


14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).


14(e). If an IDN, list all code points contained in the U-label according to Unicode form.


15(a). If an IDN, Attach IDN Tables for the proposed registry.

Attachments are not displayed on this form.

15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.


15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.


16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.

We have examined the applied-for string “MERCK” and found that deployment of it would not cause adverse operational, rendering, or general user-confusion. We performed a S.W.O.R.D test, and have not found visual similarity to any existing TLDs, names on ISO3166 lists, or the ICANN reserved list of names and list of ineligible strings. As the string consists entirely of ASCII letters and is a valid hostname having at least three and less than 63 characters, the ASCII label is therefore in compliance with the string requirements set forth in the Applicant Guidebook (AGB, p. 64, section: 2.2.1.3.2 “String Requirements”), and with all technical standards including but not limited to RFC 1035, RFC 2181, RFC 952, RFC 1123, and RFC 3696. It is possible that, in general, some software applicants may have difficulty dealing with new TLD strings. The applicant is aware of its responsibility to seek to mitigate and solve, inter alia, such issues as discussed at the “TLD Universal Acceptance” session at the ICANN Meeting on March 14, 2012 (http:⁄⁄costarica43.icann.org⁄meetings⁄sanjose2012⁄presentation-tld-universal-acceptance-14mar12-en.pdf). We are aware of the following issues:

- Validity checks of TLDs based on either a hard coded list or on a length check (i.e. max. three characters)
- Name conversion in various applications and browsers. Based on wrong definitions or outdated lists of TLDs, some applications may not convert this new gTLD to links
- User acceptance. Some websites⁄applications may refuse user acceptance of users entering a new gTLD not accepted by the website⁄application
- Email clients validating on length on TLDs on by applying an outdated list of TLDs may also cause problems for this new gTLD, as valid email addresses may not be accepted
- Websites and search engines such as Google and Yahoo! may refuse to offer services such as advertising, if they validate email addresses and valid domain names based on outdated definitions of TLDs, or simply refuse to add new gTLDs to their lists
- Mobile browsers may also not be updating their lists of valid TLDs, as live DNS look ups may be considered costly or in adequate by the providers

Actions to mitigate or solve these issues:

As the TLD is longer than 3 characters, it is understood that some issues concerning usage of the TLD in online forms will exist. We will take full responsibility for any such issues and will work to ensure that this TLD receives global acceptance. We will contact websites should we notice acceptance issues, and we will monitor acceptance of the TLD by the major search engines and major social networking sites, and so on. We will ensure that all our own available online forms will be able to accept all TLDs per the IANA list. We will work with ICANN in our on-going effort on this subject both for IDN and ASCII TLDs.

For second-level IDN issues see response to Q44.

17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).


Mission/Purpose


18(a). Describe the mission/purpose of your proposed gTLD.

Merck KGaA is a global pharmaceutical, chemical and life science company with approximately 40,000 employees in over 70 countries. In 2010 Merck realized total revenues of EUR 9.3 Billion. 


A. MERCK Businesses

The pharmaceutical, chemical and life science businesses of Merck are organized into four divisions.

Merck Serono specializes in innovative pharmaceuticals and focuses on indications mainly treated by specialists, as well as on diseases with high unmet medical needs.

Merck Consumer Healthcare offers high-quality over-the-counter products to enhance the quality of life of consumers all over the world. Its brands are available in many countries throughout Europe, North and South America, Asia and Africa.

The Merck Millipore division offers solutions that enable scientists to conduct life science research easily, efficiently and economically. With a range of more than 40,000 products, Merck Millipore is one of the top three suppliers of tools to the life science industry. This division comprises three business units: Bioscience, Lab Solutions and Process Solutions.

Merck’s Performance Materials division offers highly innovative materials, advanced technologies, and high-tech chemicals to clients in the consumer electronics, lighting, printing, plastics, and cosmetics industries. Merck’s market leading products include liquid crystals for LCD displays, new lighting technologies, and functional and effect pigments.

Merck KGaA operates its worldwide business through over 250 companies which (1) are fully owned subsidiaries of Merck KGaA, (2) use Merck as the sole element or as a component of their company name, and (3) use the German figurative trademark No. 30130670, “MERCK”, as their umbrella brand. The nexus of these companies, together with the parent company Merck KGaA, constitutes the “Merck Community”.

Today there are over 250 companies in the Merck Group, with roughly 40,000 employees located in over 70 countries worldwide, which represent the Merck Community, working together to bring innovative healthcare, life science and high-tech chemical solutions to the world at large.

Only members of the Merck Community, as defined above and further discussed below under Question 20, shall be eligible to register domain names within the “.MERCK” TLD. Merck KGaA, or its express assignee, shall periodically monitor the registration status of all domain names in the “.MERCK” space to ensure ongoing compliance with this eligibility requirement. As the Registry Operator, Merck KGaA shall maintain the space for the benefit of the Merck Community at large.


B. The name and brand MERCK

Since Friedrich Jacob Merck laid the foundation stone in 1668, the name Merck has stood for medicines and chemical products that have proved invaluable to people and have created inestimable value for the company.

Today Merck KGaA holds rights in the name and the trademark “Merck” in more than 180 countries worldwide. The trademark “Merck” is considered to be well known pursuant to the Paris Convention for the Protection of Industrial Property in various countries including, for example, Bulgaria, the Czech Republic, Egypt, Germany, Japan, Mexico, South Korea, and through the Madrid System of WIPO. Merck is further regularly listed among the global Top 500 companies as published through the famous Forbes magazine.

The Merck Group has established detailed branding guidelines to ensure a globally visible corporate identity for the Merck Community. Such guidelines define the use of the umbrella logo MERCK and other design elements. They provide detailed instructions for the branding of, for example, letterheads, business cards, signage, marketing materials, brochures, products, working clothes, car fleets and trade fairs. Further, Internet and social media guidelines have been developed to ensure a harmonised appearance of the Merck group in online media. These combined efforts result in an easy recognition of the Community members as part of the Merck family.

The “.MERCK” top-level domain will enable the Merck Community to communicate with all stakeholders as one group, and to communicate information about the Merck brand in a unified and global manner. The “.MERCK” space will further help Merck unite all members of the Merck Community under one single name online, and provide the Merck Community with a universal, comprehensive forum through which to present its information to the public.

The TLD “.MERCK” is intended to benefit Internet users by enabling the Merck Community to communicate under the unique branded TLD which corresponds to Merck KGaA’s globally famous trademark. The “.MERCK” TLD will allow the Merck Community to more easily and effectively interact with all Internet users, and particularly with the Merck Group’s many customers, employees and affiliates.

The “.MERCK” TLD will be operated for the benefit of the entire Merck Community. This will allow the distribution and exchange of information between Merck KGaA, the companies of the Merck Group, and their relevant stakeholders by means of, but not limited to, websites, social networks, email and other technologies that will reside within the “.MERCK” domain name space.

Merck KGaA intends to limit eligibility for registration to itself and companies which are members of the Merck Community, and to primarily use all such domain names for promotional and navigational purposes relating to Merck’s, and the companies of the Merck Group’s, online presences and⁄or the provision of Merck’s goods and services.

The “.MERCK” domain space will further be used to communicate the global initiatives of the Merck Community, which are focused on innovation. Targeted expansion of its extensive product range is crucial for the Merck Community. Merck employees’ work and creativity provide Merck with the keys to new products for the most important markets, and Merck strives to ensure that its employees are provided with the best prerequisites and state-of-the-art resources to enable such activities. Merck continuously expands its research capabilities through acquisitions, partnerships and strategic alliances across the borders of industries and countries, thereby stretching the boundaries to make new solutions possible.

State of the art technologies combined with a modern, safe and trustworthy Internet presence within the “.MERCK” space underline Merck’s mission to deliver first class products, treatments and solutions in the business areas of chemical, pharmaceutical and life science.

18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?

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

The TLD is intended to benefit internet users by enabling the Merck Community to communicate more easily and effectively with interested visitors, and particularly with the Merck Community’s customers, employees and business associates. Internet users will benefit from a more distinctive and trustworthy Internet experience in dealing with the members of the Merck Community, thus supporting Merck KGaA’s goal of communicating a message of reliability and trust.

The Merck Community expects to benefit from the TLD by increased and more effective brand recognition in their marketing and communications, and by having an ample supply of relevant domain names to use in their businesses. In addition, the TLD will permit the members of the Merck Community to have greater control over their online brand and services, including but not limited to robust trust and security features, especially for Merck’s online sales portals. In turn, these benefits are certain to result in a better Internet user experience.

The “.MERCK” space will bring the additional benefit of Internet user security. The Merck Community offers innovative products and solutions in the business fields of pharmaceuticals, chemicals and life sciences. Interested customers, e.g. scientists, laboratory staff, patients, healthcare professionals and industrial centers which process Merck goods, need to rely on the constant quality of the Merck Group’s products. No matter where they are located across the globe, individuals seeking information concerning their medications, prescriptions, or laboratory devices will have heightened assurance that what they find in “.MERCK” will be trustworthy and safe. They will know that Merck is diligent in its efforts to eliminate counterfeit medications, harmful substances or dangerous advice via the “.MERCK” TLD. This peace of mind cannot currently exist within the landscape of today’s DNS, where it is impossible for a corporate community to monitor the content of every typosquatted gTLD or ccTLD domain name. Only through the operation of the clean space found within “.MERCK” can the Merck Community’s customers, and the wider Internet public, intuitively rely on the information they find about Merck online.

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

The TLD ultimately is intended to serve as the Merck Community’s online branding and services platform. It is intended to function with leading-edge technologies and business practices, ensuring a trustworthy and positive user experience for Internet users seeking to interact online with the Merck Community. The Merck Community anticipates having an ample supply of relevant domain names available for its use, which will assist in the marketing of Merck products, the delivery of Merck products and services, and the development of new services.

All “.MERCK” domain name registrations will incorporate the “.MERCK” Registration Restrictions and Use Policy (“the Policy”), which limits the use of “.MERCK” domain names to the purposes supported by the Merck Community (outlined in the answer to Question 18(c) below). The terms of this agreement will be enforced via monitoring. The registration of a domain may be revoked by Merck KGaA at any time if the registrant does not comply with the Acceptable Use Guidelines contained in Section P of the Policy. A full text version of the draft “.MERCK” Registration Restrictions and Use Policy is provided in the answer to Question 28.

Once registered, individual domain names within the “.MERCK” space may be used to provide specific information relevant to particular geographic locations, product lines or research activities. For instance, patients seeking information about a particular medication might search for the name of the drug at PRODUCTNAME.MERCK, or research professionals inquiring about new laboratory equipment might begin their search at EQUIPMENTNAME.MERCK. Thus, “.MERCK” domains will indicate clearly to consumers the content available at the corresponding websites, providing users with an enhanced Internet experience.

This user-friendly, specialized approach to domain name registration and content display will greatly benefit consumers and Internet users, thus enhancing the reputation of Merck KGaA and the Merck Community, and instilling a high level of trust in those who visit “.MERCK.”

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

The TLD will provide an alternative for the companies of the Merck Community to the current TLDs. The branded, differentiating nature of the TLD will provide a distinctive name space that simplifies users’ choice to interact with the Merck Community. Internet users will be able to directly navigate to intuitive domains and subdomains, saving the time of a search engine. It is expected that consumers will soon learn to distinguish branded spaces from the existing TLDs and from generic, geographical or cultural TLDs. The use of a specialized TLD by the Merck Community will impact competition by clarifying for users the source identity of the websites which they choose to visit.

This streamlining of information will provide a great benefit to the virtual marketplace. Consumers will know where to look for authentic Merck Community products and information, and can select appropriate websites. The new “.MERCK” TLD space will therefore express the Merck Community’s core competencies - its innovative strength and strong customer focus – while providing users with an intuitive, easy-to-use and secure location.

Additionally, the use of the “.MERCK” TLD will have the added benefit of reducing the number of domain name registrations that the companies of the Merck Community will need to maintain. This effect, multiplied across the many companies who will own and operate their own TLDs, may result in increased competition among existing registration providers. The logical effect should be lower pricing and better service for all Internet users.

The “.MERCK” TLD will allow the companies of the Merck Community to develop uses for domain names which today are too complicated or completely unforeseen. Today, it is often difficult to find a relevant domain name for the launch of a new product or campaign from existing registration providers. Even if one is found, pricing is often prohibitive because the domain is only available on the secondary market. New domains must be purchased from third parties and managed as corporate assets. These expenses and complications which can hinder companies and, in some cases, delay the release of innovative new products and services to the public, can be dramatically reduced. Furthermore, an ample supply of immediately available domain names, relevant to the companies of the Merck Community, is likely to pay dividends in additional, unforeseen ways.

The “.MERCK” TLD will enable the Merck Community to provide their innovative goods and solutions within a distinctive and reliable Internet space. The Merck Community’s TLD will offer the most recent innovations in the field of chemicals, pharmaceuticals and life sciences. Furthermore, the proposed “.MERCK” TLD will be a “clean space” for consumers seeking information about the Merck Community’s research, innovation and community activities. Since Merck KGaA will have control over all of the registrations in the space, there is minimal risk of abusive use of these domain names. There will be far less opportunity for bad actors to sell dangerous counterfeit medications or provide harmful misinformation to consumers. The Merck Community intends that internet users will find only authentic, Merck-authorized content within this space, providing them with a level of comfort and safety which the current gTLD landscape cannot give them. The “.MERCK” pages will connect Internet users to the worldwide Merck Community, helping users to find the resources and information relevant to their geographic regions and individual needs.

A.3 What goals does your proposed gTLD have in terms of user experience?

The TLD ultimately is intended to serve as the Merck Community’s online branding and services platform supporting the goals of the “.MERCK” space. It is intended to function with leading-edge technologies and business practices, ensuring a trustworthy and positive user experience.

The goal is to use “.MERCK”’s online infrastructure, services and marketing to encourage Internet users to interact online with the Merck Community and to perceive the TLD as a trustworthy source of Merck’s information and services. The Merck Community will use advanced technical and policy measures to ensure the security of the space, and that domains in the TLD are only used for authorized purposes. The Merck Community intends to provide a safe, legitimate Internet space, enhancing user experience by mitigating security-associated risks. This is particularly important in the “.MERCK” space, as the members of the Merck Community are engaged in the pharmaceutical, chemical and life science industries, where Internet user safety and security are of paramount importance.

Domain usage guidelines (see also Question 20 below) will be established and enforced, to constantly reinforce the “.MERCK” experience and the reputation of the space. In addition, the TLD will provide an easily navigable and predictable domain name space.
The Internet user can expect, when entering the “.MERCK” TLD, to find authentic, up-to-date information displayed in an intuitive, easy-to-navigate fashion. Second-level registrations will be carefully allocated, and their content routinely monitored, by Merck KGaA to ensure that Internet users receive the maximum benefit when utilizing the “.MERCK” space. For example, if a visitor is looking for specific information about the product Nasivin®, the visitor might enter “www.nasivin.merck” into his or her web browser. The resulting page would detail the history, product information, and current news about the Nasivin® medication.

Thus, the “.MERCK” space is designed to provide an unparalleled user experience in terms of reliability, ease of use, and patient safety.


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

It is envisaged that the companies of the Merck Community will be the sole registrants of domain names within the TLD. Additionally, the Corporate Trademark Department of Merck KGaA will review and approve each applied-for second-level domain name string to ensure that it will further the goals of the Merck Community, that it will not violate the intellectual property rights or other rights of third parties, and that it will not violate existing laws. These registration restrictions, and Merck KGaA’s ongoing monitoring of the “.MERCK” space, will ensure that such domain names only are used for purposes authorized by Merck KGaA.

Registration of a “.MERCK” domain name will be done in 3 steps: Approval of the Community Member, Approval of the Domain Name, and Registration. After Registration, the holder of a “.MERCK” domain name must comply with the Acceptable Use Guidelines (further outlined below in the answer to Question 18(c)).

B.1 Step 1 – Approval of the Community Member

Each Registrant must be recognized as member of the Merck Community as defined above under Question 18(a). Upon receiving a request from a potential registrant, the Corporate Trademark Department at Merck KGaA will perform an eligibility assessment, to determine whether the applicant qualifies as a member of the Merck Community. This process will include an application form that the prospective member must fill out, and verification of the applicant’s identity by Merck KGaA. If successful, such assessment will be concluded by assigning a ʺMerck Community Membership IDʺ to the new member. Once a member has obtained a Merck Community Membership ID, the member is entitled to register domain names within the “.MERCK” TLD that have been approved by the Corporate Trademark Department of Merck KGaA.

The member approval step needs to be performed only once for each member⁄registrant. The member’s Merck Community Membership ID is a permanent assignment, and will remain the same for all of that member’s domain name registrations.

B.2 Step 2 - Approval of the Second-Level-Domain by the Corporate Trademark Department of Merck KGaA

Before registering a domain name, each member must ask the Corporate Trademark Department of Merck KGaA for approval of the second-level string text. A domain name within the “.MERCK” TLD must:

- further the mission and purpose of the Merck Community;
- must not violate or contribute to the violation of the intellectual property rights or other rights of any other party; and
- must comply with any applicable laws, government rules or requirements

If the Corporate Trademark Department of Merck KGaA determines that the requested second-level domain name meets the above requirements, it will consent to such registration by the Community Member. The applicant will receive written notification from the Corporate Trademark Department, either consenting to or rejecting the domain request. Such notification will either take the form of an Approval Statement or a Rejection Statement, depending on Merck KGaA’s assessment.

B.3 Step 3 – Registration

When a second-level string request has been approved by the Corporate Trademark Department of Merck KGaA, a prospective registrant may contact an ICANN-accredited registrar to register the approved second-level string and pay the registration fee. The Merck Community Membership ID can be reused for multiple registrations by the same Registrant, and must be provided in the domain Create attempt submitted into the registry by the registrar. Create attempts that are not accompanied by a valid Community Membership ID will be automatically rejected by the registry system.

Once the domain Create request has been received at the registry, the domain record will be placed on a “Pending Create” status. This status includes an EPP ServerHold status, placed on the domain record so that the domain cannot resolve. The Registry Operator will then have the opportunity to view the pending domain name, and will be able to either approve the “Pending Create” (thus releasing the Hold status and enabling the Registrant to use the requested domain, or to reject the Create (which will delete the Registrant’s application for the domain name). The Merck KGaA legal team that reviews membership applications and approves domain strings will review all of the Pending Creates, and will compare those pending Creates with the membership and approved string data in its files.

This procedure will ensure that only qualified members of the Community can register domain names in the TLD, and that only approved domains can be used.

Merck KGaA, as the Registry Operator for “.MERCK,” and Afilias Limited have developed the necessary mechanism by which the Merck Community Membership ID and domain name registration authorization systems will function, in order to ensure that the process will operate smoothly and easily for all concerned actors, including for the domain name registrars.


C. Will your proposed gTLD impose any measures for protecting the privacy or confidential information of registrants or users?

The Merck Community intends for users to perceive the “.MERCK” TLD as a trustworthy indicator of the source of the Merck Community’s online information and services. User trust is enhanced when said users are confident that they are in fact interacting with the intended website, and that their confidential information is securely protected. The Merck Community intends to use advanced technical and policy measures to reasonably ensure the security of online transactions and communications, and to reasonably ensure that domain names in the TLD are only used for authorized purposes. The Merck Community intends to provide a safe and legitimate Internet space, enhancing user experience by mitigating security-associated risks.

Merck KGaA intends to deploy DNSSEC and to comply with all of the other policies and practices required by ICANN in the Registry Agreement and⁄or via any Consensus Policy. Merck KGaA will also comply with all applicable laws and regulations relating to Internet security and the privacy of users’ confidential information.

Merck KGaA already employs commercially reasonable practices with respect to the security of online transactions and users’ private or confidential information in its current online locations.

Additionally, Merck KGaA makes available a Corporate Privacy Officer, who oversees any potential privacy concerns, should they arise, and ensures that Merck’s practices remain industry-leading. For further information concerning privacy protections and data security within the “.MERCK” space, please refer to the answers contained in sections 23, 30a and 30b below.


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

Within the Merck Community, the “.MERCK” TLD will be promoted by all available internal communication channels, including the Community’s intranet, the Community’s magazine, and through the relevant functions of the Corporate Trademarks and Corporate Information Services departments, inter alia.

Additionally, Merck KGaA plans to advertise the TLD in many of its marketing initiatives, and envisages that members of the Merck Community will use “.MERCK” domain names in relation to many of their core operations and services. Use of the TLD in this way will effectively communicate to the intended audience the opportunities available to them within the TLD. Not only will such marketing inform individuals and health networks about the information available at “.MERCK” for the particular goods or services covered in the advertising, but will also introduce them to the many other opportunities available within the TLD. Once familiar with the space, they may explore the easy-to-use, intuitive layout of the space overall.

Besides the Merck Community’s specific efforts to communicate the “.MERCK” TLD to its audience, it will be the natural next step for consumers, and relevant media organizations, to further communicate information about the TLD as they speak or report about Merck. Outreach and communication are important in order to achieve the projected benefits of the TLD, but also will be inherent in the Merck Community’s use of the TLD, and further will be enhanced by the viral nature of communications about Merck KGaA and the Merck Community.

As it seems there will be many “.BRAND” TLDs presented to Internet users in the coming years, it is expected that the outreach, communications and media relating to each of them, individually, will lead to collective benefit. Internet users will grasp the concept behind these TLDs, and will expect companies and corporate communities to operate them in generally consistent ways.

18(c). What operating rules will you adopt to eliminate or minimize social costs?

The TLD ultimately is intended to function as the Merck Community’s online branding and services platform. It is intended to function with leading-edge technologies and business practices, ensuring a trustworthy and positive user experience. The goal is to use Merck’s online infrastructure, services and marketing to encourage Internet users to interact online with the members of the Merck Community. Precise details are set forth in the answers to Questions 26, 28 and 29.

In general, Merck KGaA intends for users to perceive the TLD as a trustworthy and intuitive indicator of the source of the Merck Community’s online information and services. The Merck Community intends to use advanced technical and policy measures to ensure the security and reliability of online transactions and communications taking place on domains within the TLD, and to ensure that domain names in the TLD are only used for purposes authorized by Merck KGaA. The Merck Community intends to provide a safe and trustworthy Internet space, enhancing user experience by mitigating security-associated risks.

The TLD is designed to reinforce the ideals of the Merck Community, and to provide an online forum for the collective benefit of the entire Merck Community. Therefore, domain usage guidelines will be implemented and enforced to constantly ensure the integrity of users’ “.MERCK” experience and the reputation of the TLD.

As all registrants of “.MERCK” domain names will be members of the Merck Community, and as such have a strong vested interest in the proper management of the space in line with their common goals, registrants agree through the “.MERCK” Registration Restrictions and Use Policy that Merck KGaA shall have discretion to monitor and manage the new TLD for the benefit of the Merck Community at large. The “.MERCK” Registration Restrictions and Use Policy (a draft version of which is supplied with this application, in the answer to Question 28, for illustration purposes only) provides the Acceptable Usage Guidelines (in Section P of the Policy) applicable to all “.MERCK” domain names. All “.MERCK” domain names shall be used:

- to further the mission and purpose of the Merck Community;
- to display only content related to the Merck Community’s activities

Furthermore, “.MERCK” domain names shall not be used in any way that:

- infringes any other third party’s rights
- is in breach of any applicable laws, government rules or requirements

or for the purposes of:

- undertaking any illegal or fraudulent actions, including spam or phishing activities,
- defaming Merck KGaA or the Merck Community, its businesses, employees, etc.;
- displaying pay-per-click links through a “parked” page; or
- “warehousing” or otherwise failing to use the domain name to link to active content

The “.MERCK” domain space shall be used for the benefit of the Merck Community at large, and all registrants shall cooperate to achieve this common goal. Merck KGaA will have the right to revoke any domain name registration or re-allocate any domain name registration to a different Community member should Merck KGaA deem such action appropriate for the benefit of the Community.

The registrations and use of all registered “.MERCK” domain names will be monitored by Merck KGaA on an ongoing basis, and compliance with the contractual restrictions and guidelines will be enforced. Violations of any restrictions, guidelines or other contractual conditions may result in termination of the relevant domain name registration or, in appropriate circumstances, the revocation of the Merck Community Membership ID.

In addition, the TLD will provide an easily navigable and predictable domain name space. This is due to the anticipated intuitive navigation approach to be adopted within the TLD. For example, domain names in the format “FUNCTION.MERCK” may be utilized for websites related to particular company functions, or “PRODUCT.MERCK” for websites related to specific products. All of this will lessen users’ confusion when interacting online with the Merck Community, and make it easy for them to find the resources and information they seek.

Merck KGaA will implement a Sunrise period of 30 days for the purpose of complying with ICANN requirements. However, because the Registry Operator and the other Merck Community members will be the sole registrants within this space, there will be no other registrants eligible to reserve or register domain names during this period. The Registry Operator will develop and implement an appropriate Sunrise Dispute Resolution Policy (SDRP), containing the elements specified by ICANN, for the resolution of any disputes which might in theory arise during this period.

During the initial launch period, for no less than 60 days, a Trademark Claims Services system will be in place as required by ICANN. During this period there will be a notice sent to the prospective registrant of any “.MERCK” domain name, prior to its registration, should such domain name constitute an identical match of a mark registered in the Trademark Clearinghouse. Moreover the right owner or owners, as recorded in the Trademark Clearinghouse, will be informed once any such domain name has been registered following this event.


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

As described in detail above under section 18(b), prospective registrants in the “.MERCK” space must contact Merck KGaA to request a Merck Community Membership ID and an Approval Statement authorizing the registration of each specific second-level domain name. Every domain name registration will require a new Approval Statement, and thus Merck KGaA will have the opportunity to review each registration to ensure that it meets the relevant requirements. Additionally, once a request to register any “.MERCK” domain name is received by an accredited Registrar, the Registry Operator shall have the opportunity to review the “Pending Create” record in the registry, to determine whether the application meets all required criteria and to ensure that each registration issued will be in the best interests of the Merck Community at large.

Merck KGaA does not anticipate there to be multiple applications for a particular domain name. If, however, two registration requests for the same second-level string were to be received by Merck KGaA simultaneously, Merck KGaA would evaluate both requests on the basis of the specified criteria and determine which registrant, if either, should be granted the registration.

Under the “.MERCK” Registration Restrictions and Use Policy, registrants will agree that Merck KGaA shall operate the space to ensure maximum benefit to all members of the Merck Community and the Internet users of the Merck websites. Therefore, Merck KGaA will have discretion to make necessary changes to domain name registrations within the space, and to monitor the use of such domain names to ensure compliance with the Acceptable Use guidelines (as outlined in Section P of the Policy). The “.MERCK” Eligibility and Functionality Reconsideration Policy, discussed further below under Question 20, would provide any registrant with recourse should they disagree with a decision by Merck KGaA concerning a registration within the space.

This system of strong oversight by Merck KGaA will ensure that the TLD remains a tightly controlled, safe space for Internet users, and will ensure that the network of registrations remains well-organized. These protections will naturally inure to the benefit of Internet users who wish to interact or communicate with the Merck Community.


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

As outlined above, all domain name registrations in the “.MERCK” space will be held by members of the Merck Community, and pricing (if any) of domain registrations will be a matter of Merck KGaA policy.


C. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation?

The companies of the Merck Community will be the sole registrants of all domains in the TLD, in the interests of Internet users who wish to interact or communicate with the Merck Community online. There will be time and cost benefits to those users, via easier navigation and more trustworthy interaction with the Merck Community.

To the extent the members of the Merck Community are eligible to register domain names, it is likely that the domain name registration will be a small part of a larger relationship, and thus ‘price’ of the domain registration would be relatively insignificant. The importance of domain name pricing is further minimized since the domains would have no value if registered or used in any manner unauthorized by Merck KGaA.

The cost of domain registration to members of the Merck Community will naturally be minimal in light of the greater relationship between the Community members.

Community-based Designation


19. Is the application for a community-based TLD?

Yes

20(a). Provide the name and full description of the community that the applicant is committing to serve.

The community served by the “.MERCK” TLD space is the collection of corporate entities, their affiliates and subsidiaries which together comprise the Merck Community. Membership in the Merck Community is clearly defined in the following manner.

Members of the Merck Community are the companies which are part of the Merck Group (as also discussed above in the answer to Question 18). To be recognized as a member of the Merck Community, a registrant must meet the Eligibility Requirements, which are as follows:

- the registrant is Merck KGaA or a company which is a fully owned subsidiary of Merck KGaA,
- the registrant uses “Merck” as the sole element or as a component of its company name, and 
- the registrant uses as its umbrella brand the German figurative trademark No. 30130670, “MERCK”

Merck KGaA keeps an up-to-date, comprehensive list of the members of the Merck Community at all times. Thus, the Merck Community is very clearly defined.

The structure of the Merck Community is thus identical with the intra-corporational hierarchy of the Merck Group, discussed in detail above in the answer to Question 11. Merck KGaA, the Applicant for the “.MERCK” TLD, is the parent company of the Merck Group, and thus the representative and leader of the Merck Community. All members of the Merck Community are engaged in activities concerning the manufacture, research, development, marketing or distribution of Merck-branded pharmaceuticals and laboratory equipment. Merck KGaA shall maintain the space for the benefit of the Merck Community at large.

As the parent company, Merck KGaA oversees over 250 corporate entities working together towards a common goal. In practice, these over 250 companies provide goods and services within the Group’s four divisions, detailed above, which comprise: Merck Serono, Merck Consumer Healthcare, Merck Millipore, and Merck Performance Materials. Additional information about each of these divisions may be found in the answers to Question 18(a).

The Merck Community was affirmatively established in 1968, the year which marked the 300th anniversary of Merck. In 1968, the individual companies comprising the Merck Group realized that a common identity was paramount to successful communication and effective worldwide branding. At that time, the Merck Group published its first consolidated financial report including information from the territories outside Germany. A new corporate logo was adopted, which came to define the Merck Community, which has grown both in breadth and strength over the past four decades. Today there are over 250 companies, with roughly 40,000 employees, which represent the Community, working together to bring innovative healthcare solutions, cutting edge pharmaceuticals, world-class laboratory equipment, and high-tech chemical and material solutions to the world at large.

The Merck Community is further globally engaged in various social projects. Taking on responsibility has been a characteristic element of its culture and actions for many generations. The Merck Community sees itself as part of society – at its individual locations and globally. The Merck Community takes responsibility for all of its activities regardless of whether they relate to products or employees, the environment or the community.

The Merck Community views its corporate responsibility toward society not only in terms of paying taxes and creating or maintaining jobs. Rather, the Merck Community is convinced that it can make an important contribution to society with its knowledge, its skills and its products.

Merck manufactures more than 50,000 different products at 70 production sites. Merck aims to prevent negative environmental impact caused by the production of pharmaceuticals, chemicals and laboratory products, and to provide its employees with a safe work environment.

Merck has further committed itself to the Responsible Care® principles of the chemical industry and to the Responsible Care Global Charter.

Additionally, Merck is taking steps to advance the objective of making our health solutions accessible and affordable for patients in developing countries.

A detailed report about the activities within the Merck Community can be found on Merck KGaA’s website, in the document entitled Corporate Responsibility Report 2011.

It is reasonable and natural to think of this collection of corporate entities as a community due to the common goals and activities shared among the group, its unitary nature as distinct from competitors or other organizations, and its international representation. The Merck Group is located in over 70 countries worldwide, yet all of its individual members share the same mission statement and common purpose.

20(b). Explain the applicant's relationship to the community identified in 20(a).

The applicant for the “.MERCK” gTLD is Merck KGaA, the parent company of the Merck Group and thereby the leader of the Merck Community. As their corporate parent, Merck KGaA is accountable to its subsidiaries and affiliates for successful governance, guidance and leadership. With respect to the new “.MERCK” space, Merck KGaA will be responsible for providing a common vision for the TLD, and for implementing and maintaining the applicable registration restrictions and use guidelines established for the space. Merck KGaA will be responsible for reviewing applications for Merck Community Membership IDs, and thereby ensuring that only Merck Community members will have access to “.MERCK” registrations. Merck KGaA will also be responsible for communicating with its designated Registry Service Provider Afilias Limited, and overseeing the monitoring process to ensure that all “.MERCK” websites are properly maintained.

20(c). Provide a description of the community-based purpose of the applied-for gTLD.

The purpose of the “.MERCK” TLD is to enhance communication within, and to raise awareness, heighten confidence, and ensure integrity of information concerning the activities and products of the Merck Community worldwide. This specialized TLD will be an invaluable asset to the Merck Community, will enable secure communication between members of the Community, and will provide a common platform for all of the constituent participants to showcase their achievements together. Additionally, it will provide a secure, trustworthy network of information for end-users seeking to interact with the members of the Merck Community worldwide.

The intended registrants of the “.MERCK” space are limited to members of the Merck Community, meaning that only companies which are a part of the Merck Group may apply.

The intended end-users of the TLD will be Internet users across the globe who are seeking information about the Merck Community and its varied activities. This would naturally include patients, consumers, laboratory researchers, physicians, pharmacists, hospitals, medical conglomerates, investors, current and future employees, as well as any interested members of the general public. An additional benefit to end users is the increased safety of the controlled TLD space, as the Community’s stakeholders will have heightened assurance they are viewing only authorized content and authentic products when accessing “.MERCK” websites.

Merck KGaA has been in the pharmaceutical business since 1668, and is the oldest business of its kind in the world. The Merck Group has been working together, and has collectively branded tens of thousands of products and services on a worldwide scale, since 1968. Therefore, it is clear to see that this Community has withstood the test of time. The Merck Community intends to remain a leader well into the future, and to provide the best possible information and products to its consumers through the continued use of the “.MERCK” platform.

20(d). Explain the relationship between the applied-for gTLD string and the community identified in 20(a).

The applied-for “.MERCK” string is identical to the Merck Community’s distinctive corporate name and globally famous trademark. The individual companies which comprise the Merck Community actively self-identify as members of the Merck Community, and utilize the Merck name within their own corporate titles. Members of the public recognize the name Merck as corresponding to the Merck Community and its constituent members.

The word “Merck” has no dictionary or generic meaning, but denotes the Merck Community’s products and worldwide identity.

20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.

The registration criteria for the “.MERCK” space will be tailored to serve the Merck Community and to provide clarity for Internet users. Specifically, the process will contain four components, consisting of: 1) registration restriction, including the prohibition of Reserved or Geographic second-level strings, 2) content restriction, ensuring that the “.MERCK” space is used only for Community purposes and for the benefit of the Community, 3) an ongoing monitoring and verification process, and 4) dispute resolution procedures. For the full text, see the “.MERCK” Registration Restrictions and Use Policy in Question 28.


A. Registration

- Eligibility Requirements. To be recognized as a member of the Merck Community, a Registrant must meet the Eligibility Requirements, which are:

- the Registrant is either Merck KGaA, the Registry Operator of the gTLD “.MERCK,” or is a company which is a fully owned subsidiary of Merck KGaA,
- the Registrant uses “Merck” as the sole element or as a component of its company name, and 
- the Registrant uses as its umbrella brand the German figurative trademark No. 30130670, “MERCK”

If a member of the Merck Community wishes to register a “.MERCK” domain name it must first request, and receive, a Merck Community Membership ID from Merck KGaA. Additionally, it must request and receive an Approval Statement for the specific second level string, as detailed above under Question 18(b). The registrant must provide its Merck Community Membership ID in any application for a “.MERCK” domain name through an accredited registrar.

- Registration Process. Registration of a “.MERCK” domain name is done in 3 steps: Identification of the Registrant, Approval of the Domain Name, and Registration. A detailed outline of this process is provided above in section 18(b). After Registration, the holder of a “.MERCK” domain name must comply with the Acceptable Use Guidelines (see Question 18(c)).

- Application for a Merck Community Membership ID. A prospective registrant must request a Merck Community Membership ID from Merck KGaA prior to submitting a registration request to a registrar. Such request for a Merck Community Membership ID must provide evidence of the applicant’s Community Member status and an express agreement to the requirements set out in the “.MERCK” Registration Restrictions and Use Policy.

If Merck KGaA determines that the prospective registrant is a member of the Merck Community, Merck KGaA will issue a Merck Community Membership ID. If Merck KGaA declines to issue a Merck Community Membership ID, the prospective applicant may pursue a review of this decision through the “.MERCK” Eligibility and Functionality Reconsideration Policy (“MEFRP”)(see Question 29).

A.1 String Requirements 

Second-Level Domain names within the “.MERCK” TLD must only include hyphens in the third and fourth position if they represent valid internationalized domain names in their ASCII encoding (for example ʺxn--ndk061nʺ), and must otherwise comply with any other applicable ICANN requirements.

A.2 Reserved Names

- The label “EXAMPLE” shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations

- Two-character labels. All two-character labels shall be initially reserved. The reservation of a two-character label string may be released to the extent that Registry Operator reaches agreement with the government and country-code manager. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes

- Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the TLD: NIC, WWW, IRIS and WHOIS

- The List of Reserved Names shall be compiled by Merck KGaA and will be publicly posted online at [website to be determined]. Merck KGaA reserves the right to include new names in the list of reserved names, and to later add names to such list as it deems reasonably necessary for the benefit of the Merck Community

A.3 Country and Territory Names

The country and territory names contained in the following lists shall be initially reserved: the English short form of names on the ISO 3166-1 list; the UN’s Technical Reference Manual for the Standardization of Geographical Names, Part III; and the list of UN member states in 6 official languages, provided that specific names may be released to the extent that the Registry Operator reaches an agreement with the applicable government(s), and further provided that the Registry Operator may also propose release of these reservations, subject to ICANN review (full version at Q28).


B. Regulated second-level names within the “.MERCK” TLD

B.3 Eligibility

A registrant will be allowed to register any second-level name which follows the string requirements and common rules described above, and which has been previously approved by the Corporate Trademark Department at Merck KGaA in an Approval Statement issued to the registrant (outlined in 18(b)).

B.4 Allocation
Domain names will be allocated on a ʺfirst come, first servedʺ basis, subject to Merck KGaA Corporate Trademark Department’s prior approval. Registrations must further the mission and purpose of the Merck Community, not infringe any third-party rights, and comply with any applicable laws, government rules or requirements.

Merck KGaA has the authority to make changes to any domain name registration in the “.MERCK” space for the benefit of the Merck Community at large. Any registrant who disputes an action taken by Merck KGaA regarding a registration will have recourse under the MEFRP.

B.5 Registration Rules

Registration period and renewals. A “.MERCK” domain name may be registered or renewed subject to the current terms and conditions offered by the concerned Registrar.

Continuing eligibility. If a “.MERCK” registrant ceases to be a member of the Merck Community, then its “.MERCK” domain names may immediately be revoked and⁄or transferred at the discretion of Merck KGaA. Additionally, Merck KGaA will undertake ongoing monitoring activities to ensure that all registrants of “.MERCK” domain names remain bona fide members of the Merck Community. Additionally, if a registrant fails to comply with the terms and conditions set out in the “.MERCK” Registration Restrictions and Use Policy, Merck KGaA may in its sole discretion elect to transfer, cancel or revoke any relevant domain name registration(s) held by said registrant.

Transfers. A “.MERCK” domain name registrations may be transferred where: a) the company to whom the “.MERCK” domain name is to be transferred to meets the criteria set out in the “.MERCK” Registration Restrictions and Use Policy, b) the prescribed fee is paid, and c) Merck KGaA has previously approved the transfer of the domain name registration from the Transferor to the Transferee.


C. Content and Acceptable Use

Acceptable Use of “.MERCK”. All registrants will agree to abide by the Acceptable Use Guidelines established in the “.MERCK” Registration Restrictions and Use Policy. At a minimum, all “.MERCK” domain names shall be used to further the mission and purpose of the Merck Community, and to display only content related to the Community’s activities.

Furthermore, “.MERCK” domains shall not be used in any way that infringes third parties’ rights, is in breach of any applicable laws, government rules or requirements, to undertake any illegal or fraudulent actions (including spam or phishing activities), to defame the Merck Community, its businesses, employees, etc., to display pay-per-click links through a “parked” page; or to “warehouse” or otherwise fail to use the domain name to link to active content.

The “.MERCK” domain space shall be used for the benefit of the Merck Community at large. Merck KGaA will monitor the space and shall have the right to revoke any domain name registration or re-allocate any domain name registration to a different Community member should Merck KGaA deem such action appropriate for the benefit of the Community. Any registrant who disagrees with a decision taken by Merck KGaA regarding a domain name it has registered will have recourse under the MEFRP.


D. Ongoing Monitoring and Verification

Merck KGaA will “police” the Merck Community’s online space, which will reduce the risk of abuse. Merck KGaA will operate a verification system to prevent the misuse of Membership IDs and to ensure compliance with the “.MERCK” Registration Restrictions and Use Policy. Verification may be conducted by Merck KGaA directly or an assignee.

The verification process will ensure that each registrant still qualifies as a member of the Merck Community, and that domain names link to appropriate content.

Merck KGaA, as the Registry Operator, is responsible to the members of the Merck Community for the effective management of the “.MERCK” space, and accordingly will reserve the right in the “.MERCK” Registration Restrictions and Use Policy to make changes to domain name registrations (including their cancellation or transfer) as deemed necessary in the best interests of the Community at large. Any registrant who disagrees with a decision taken by Merck KGaA regarding a registration will have recourse under the MEFRP.


E. Dispute Resolution

A number of dispute resolution mechanisms will be available to third parties and⁄or Merck Community members including the: Trademark Post-Delegation Dispute Resolution Procedure, Registry Restrictions Dispute Resolution Procedure, Uniform Domain Name Dispute Resolution Policy, Uniform Rapid Suspension System, Charter Eligibility Dispute Resolution Policy, and the .MERCK Eligibility and Functionality Reconsideration Policy (see Question 29).

20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).

Attachments are not displayed on this form.

Geographic Names


21(a). Is the application for a geographic name?

No

Protection of Geographic Names


22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD.

This response describes protection of geographic names as implemented in the managed TLD registry service.


A. Protection of geographic names

In accordance with Specification 5 of the New gTLD Registry Agreement, the Registry Operator must initially reserve certain geographic names at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations. We will satisfy this requirement by using the following internationally recognized lists to develop a comprehensive master list of all geographic names that will be initially reserved:

- The 2-letter alpha-2 code of all country and territory names contained on the ISO 3166-1 list, including all reserved and unassigned codes [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-31661_ decoding_table.htm];
- The short form (in English) of all country and territory names contained on the ISO 3166-1 list, 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 [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-31661_ 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. This lists the names of 193 independent States generally recognised by the international community in the language or languages used in an official capacity within each country [http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄ungegn%20tech%20ref%20manual_M87_combined.pdf]; and
- The list of UN member states in six official UN languages prepared by the Working Group on Country Names of the United Nations Conference on the standardization of Geographical Names [http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄UNGEGN⁄docs⁄9th-uncsgndocs⁄ econf⁄9th_UNCSGN_e-conf-98-89-add1.pdf]

Names on this reserved list in the TLD registry will be prevented from registration, unless and until any such names are released from reservation per our release procedures generally described below. We do not plan on offering internationalized domain names (IDNs) upon launch, but if we ever do offer IDNs, we will reserve relevant IDN versions of country names.

Before the Sunrise opens, the list of reserved geographic names will be made available to the public via the Registry Operator’s website in order to inform Registrars and potential Registrants of the reserved status of such names. The lists previously noted, will be regularly monitored for revisions and the reserved list, both within the registry and publicly facing, will continually be updated to reflect any changes.

In addition to these requirements, our services provider Afilias is able to support our wishes in regards to the reservation of additional terms on a case-by-case basis. The managed TLD registry allows such additions to the reserved list to be made by appropriately authorized staff, with no further system development changes required.

The following applies to all domain names contained within the managed TLD registry reserved list:

- Attempts to register reserved domain names will be rejected;
- WHOIS queries for listed domain names will receive responses indicating their reserved status;
- Reserved names will not appear in the TLD zone file; and
- DNS queries for reserved domain names will result in an NXDOMAIN response.


B. Procedures for release

Specification 5 says that “the reservation of specific country and territory names may be released to the extent that Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.”

In order to satisfy this requirement, we will have in place a special release mechanism, described below.

If a country wishes to use one of the relevant “.MERCK” domain names, its GAC representative may make a written request to us, the Registry Operator, and we will immediately consider the release request.

If a member of our community wishes to use a reserved country name, we will obtain approval from that country’s GAC representative.

We will formally present the GAC with an option, at no charge, of objecting to the release and use of any initially reserved names at the second level. However, as further detailed below, since such names will be used for the purposes of the representation of our company, it is almost impossible to anticipate any abuse or misconduct. Thus we reasonably believe that very few GAC Representatives, if any, would exercise this option. Nevertheless, the at-no-charge objection will remain an option for the GAC Representatives, in compliance with current ICANN requirements regarding geographic reserved names.

Generally, it is extremely unlikely that our authorized use of any “countryname.MERCK” or “cc.MERCK” domain name could be confusing to users, or otherwise offensive to any country. To the extent that use of any “.MERCK” domain was ever deemed confusing or offensive, we will have a strong desire to resolve the situation quickly and respectfully to any affected country’s sovereign interests. At minimum, we will ensure that its designated abuse contact is aware of the additional sensitivities that may potentially arise with respect to use of “cc.MERCK” or “countryname.MERCK” domains, such that any complaints of this nature are prioritized accordingly.

Registry Services


23. Provide name and full description of all the Registry Services to be provided.

Throughout the technical portion (#23 - #44) of this application, answers are provided directly from Afilias, the back-end provider of registry services for this TLD. Merck KgaA chose Afilias as its back-end provider because Afilias has more experience successfully applying to ICANN and launching new TLDs than any other provider. Afilias is the ICANN-contracted registry operator of the “.INFO” and “.MOBI” TLDs, and Afilias is the back-end registry services provider for other ICANN TLDs including “.ORG,” “.ASIA,” “.AERO,” and “.XXX.”

Registry services for this TLD will be performed by Afilias in the same responsible manner used to support 16 top level domains today. Afilias supports more ICANN-contracted TLDs (6) than any other provider currently. Afilias’ primary corporate mission is to deliver secure, stable and reliable registry services. This TLD will utilize an existing, proven team and platform for registry services with:

- A stable and secure, state-of-the-art, EPP-based SRS with ample storage capacity, data security provisions and scalability that is proven with registrars who account for over 95% of all gTLD domain name registration activity (over 375 registrars);
- A reliable, 100% available DNS service (zone file generation, publication and dissemination) tested to withstand severe DDoS attacks and dramatic growth in Internet use;
- A WHOIS service that is flexible and standards compliant, with search capabilities to address both registrar and end-user needs; includes consideration for evolving standards, such as RESTful, or draft-kucherawy-wierds;
- Experience introducing IDNs in the following languages: German (DE), Spanish (ES), Polish (PL), Swedish (SV), Danish (DA), Hungarian (HU), Icelandic (IS), Latvian (LV), Lithuanian (LT), Korean (KO), Simplified and Traditional Chinese (CN), Devanagari (HI-DEVA), Russian (RU), Belarusian (BE), Ukrainian (UK), Bosnian (BS), Serbian (SR), Macedonian (MK) and Bulgarian (BG) across the TLDs it serves;
- A registry platform that is both IPv6 and DNSSEC enabled;
- An experienced, respected team of professionals active in standards development of innovative services such as DNSSEC and IDN support;
- Methods to limit domain abuse, remove outdated and inaccurate data, and ensure the integrity of the SRS, and;
- Customer support and reporting capabilities to meet financial and administrative needs, e.g., 24x7 call center support, integration support, billing, and daily, weekly, and monthly reporting

Afilias will support this TLD in accordance with the specific policies and procedures of Merck KgaA (the “registry operator”), leveraging a proven registry infrastructure that is fully operational, staffed with professionals, massively provisioned, and immediately ready to launch and maintain this TLD.

The below response includes a description of the registry services to be provided for this TLD, additional services provided to support registry operations, and an overview of Afilias’ approach to registry management.


A. Registry services to be provided

To support this TLD, Merck KgaA and Afilias will offer the following registry services, all in accordance with relevant technical standards and policies:

- Receipt of data from registrars concerning registration for domain names and nameservers, and provision to registrars of status information relating to the EPP-based domain services for registration, queries, updates, transfers, renewals, and other domain management functions. Please see our responses to questions #24, #25, and #27 for full details, which we request be incorporated here by reference
- Operation of the registry DNS servers: The Afilias DNS system, run and managed by Afilias, is a massively provisioned DNS infrastructure that utilizes among the most sophisticated DNS architecture, hardware, software and redundant design created. Afilias’ industry-leading system works in a seamless way to incorporate nameservers from any number of other secondary DNS service vendors. Please see our response to question #35 for full details, which we request be incorporated here by reference
- Dissemination of TLD zone files: Afilias’ distinctive architecture allows for real-time updates and maximum stability for zone file generation, publication and dissemination. Please see our response to question #34 for full details, which we request be incorporated here by reference.
- Dissemination of contact or other information concerning domain registrations: A port 43 WHOIS service with basic and expanded search capabilities with requisite measures to prevent abuse. Please see our response to question #26 for full details, which we request be incorporated here by reference
- Internationalized Domain Names (IDNs): Ability to support all protocol valid Unicode characters at every level of the TLD, including alphabetic, ideographic and right-to-left scripts, in conformance with the ICANN IDN Guidelines Please see our response to question #44 for full details, which we request be incorporated here by reference
- DNS Security Extensions (DNSSEC): A fully DNSSEC-enabled registry, with a stable and efficient means of signing and managing zones. This includes the ability to safeguard keys and manage keys completely. Please see our response to question #43 for full details, which we request be incorporated here by reference

Each service will meet or exceed the contract service level agreement. All registry services for this TLD will be provided in a standards-compliant manner.

A.1 Security

Afilias addresses security in every significant aspect – physical, data and network as well as process. Afilias’ approach to security permeates every aspect of the registry services provided. A dedicated security function exists within the company to continually identify existing and potential threats, and to put in place comprehensive mitigation plans for each identified threat. In addition, a rapid security response plan exists to respond comprehensively to unknown or unidentified threats. The specific threats and Afilias mitigation plans are defined in our response to question #30(b); please see that response for complete information. In short, Afilias is committed to ensuring the confidentiality, integrity, and availability of all information.


B. New registry services

No new registry services are planned for the launch of this TLD.


C. Additional services to support registry operation

Numerous supporting services and functions facilitate effective management of the TLD. These support services are also supported by Afilias, including:

- Customer support: 24x7 live phone and e-mail support for customers to address any access, update or other issues they may encounter This includes assisting the customer identification of the problem as well as solving it. Customers include registrars and the registry operator, but not registrants except in unusual circumstances. Customers have access to a web-based portal for a rapid and transparent view of the status of pending issues
- Financial services: billing and account reconciliation for all registry services according to pricing established in respective agreements

Reporting is an important component of supporting registry operations. Afilias will provide reporting to the registry operator and registrars, and financial reporting.

C.1 Reporting provided to registry operator

Afilias provides an extensive suite of reports to the registry operator, including daily, weekly and monthly reports with data at the transaction level that enable the registry operator to track and reconcile at whatever level of detail preferred. Afilias provides the exact data required by ICANN in the required format to enable the registry operator to meet its technical reporting requirements to ICANN.

In addition, Afilias offers access to a data warehouse capability that will enable near real-time data to be available 24x7. This can be arranged by informing the Afilias Account Manager regarding who should have access. Afilias’ data warehouse capability enables drill-down analytics all the way to the transaction level.

C.2 Reporting available to registrars

Afilias provides an extensive suite of reporting to registrars and has been doing so in an exemplary manner for more than ten years. Specifically, Afilias provides daily, weekly and monthly reports with detail at the transaction level to enable registrars to track and reconcile at whatever level of detail they prefer.

Reports are provided in standard formats, facilitating import for use by virtually any registrar analytical tool. Registrar reports are available for download via a secure administrative interface. A given registrar will only have access to its own reports. These include the following:

- Daily Reports: Transaction Report, Billable Transactions Report, and Transfer Reports;
- Weekly: Domain Status and Nameserver Report, Weekly Nameserver Report, Domains Hosted by Nameserver Weekly Report, and;
- Monthly: Billing Report and Monthly Expiring Domains Report

Weekly registrar reports are maintained for each registrar for four weeks. Weekly reports older than four weeks will be archived for a period of six months, after which they will be deleted.

C.3 Financial reporting

Registrar account balances are updated real-time when payments and withdrawals are posted to the registrarsʹ accounts. In addition, the registrar account balances are updated as and when they perform billable transactions at the registry level.

Afilias provides Deposit⁄Withdrawal Reports that are updated periodically to reflect payments received or credits and withdrawals posted to the registrar accounts.

The following reports are also available: a) Daily Billable Transaction Report, containing details of all the billable transactions performed by all the registrars in the SRS, b) daily e-mail reports containing the number of domains in the registry and a summary of the number and types of billable transactions performed by the registrars, and c) registry operator versions of most registrar reports (for example, a daily Transfer Report that details all transfer activity between all of the registrars in the SRS).


D. Afilias approach to registry support

Afilias, the back end registry services provider for this TLD, is dedicated to managing the technical operations and support of this TLD in a secure, stable and reliable manner. Afilias has worked closely with Merck KgaA to review specific needs and objectives of this TLD. The resulting comprehensive plans are illustrated in technical responses #24-44, drafted by Afilias given Merck KgaA requirements. Afilias and Merck KgaA also worked together to provide financial responses for this application which demonstrate cost and technology consistent with the size and objectives of this TLD.

Afilias is the registry services provider for this and several other TLD applications. Over the past 11 years of providing services for gTLD and ccTLDs, Afilias has accumulated experience about resourcing levels necessary to provide high quality services with conformance to strict service requirements. Afilias currently supports over 20 million domain names, spread across 16 TLDs, with over 400 accredited registrars.

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

With over a decade of registry experience, Afilias has the depth and breadth of experience that ensure existing and new needs are addressed, all while meeting or exceeding service level requirements and customer expectations. This is evident in Afilias’ participation in business, policy and technical organizations supporting registry and Internet technology within ICANN and related organizations. This allows Afilias to be at the forefront of security initiatives such as: DNSSEC, wherein Afilias worked with Public Interest Registry (PIR) to make the “.ORG” registry the first DNSSEC enabled gTLD and the largest TLD enabled at the time; in enhancing the Internet experience for users across the globe by leading development of IDNs; in pioneering the use of open-source technologies by its usage of PostgreSQL, and; being the first to offer near-real-time dissemination of DNS zone data.

The ability to observe tightening resources for critical functions and the capacity to add extra resources ahead of a threshold event are factors that Afilias is well versed in. Afilias’ human resources team, along with well-established relationships with external organizations, enables it to fill both long-term and short-term resource needs expediently.

Afilias’ growth from a few domains to serving 20 million domain names across 16 TLDs and 400 accredited registrars indicates that the relationship between the number of people required and the volume of domains supported is not linear. In other words, servicing 100 TLDs does not automatically require 6 times more staff than servicing 16 TLDs. Similarly, an increase in the number of domains under management does not require in a linear increase in resources. Afilias carefully tracks the relationship between resources deployed and domains to be serviced, and pro-actively reviews this metric in order to retain a safe margin of error. This enables Afilias to add, train and prepare new staff well in advance of the need, allowing consistent delivery of high quality services.

With over a decade of registry experience, Afilias has the depth and breadth of experience that ensure existing and new needs are addressed, all while meeting or exceeding service level requirements and customer expectations. This is evident in Afilias’ participation in business, policy and technical organizations supporting registry and Internet technology within ICANN and related organizations. This allows Afilias to be at the forefront of security initiatives such as: DNSSEC, wherein Afilias worked with Public Interest Registry (PIR) to make the “.ORG” registry the first DNSSEC enabled gTLD and the largest TLD enabled at the time; in enhancing the Internet experience for users across the globe by leading development of IDNs; in pioneering the use of open-source technologies by its usage of PostgreSQL, and; being the first to offer near-real-time dissemination of DNS zone data.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS.  HENCE, THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE AS INTENDED.  THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.


Answers for this question (#24) are provided directly from Afilias, the back-end provider of registry services for this TLD.

Afilias operates a state-of-the-art EPP-based Shared Registration System (SRS) that is secure, stable and reliable. The SRS is a critical component of registry operations that must balance the business requirements for the registry and its customers, such as numerous domain acquisition and management functions. The SRS meets or exceeds all ICANN requirements given that Afilias:

- Operates a secure, stable and reliable SRS which updates in real-time and in full compliance with Specification 6 of the new gTLD Registry Agreement;
- Is committed to continuously enhancing our SRS to meet existing and future needs;
- Currently exceeds contractual requirements and will perform in compliance with Specification 10 of the new gTLD Registry Agreement;
- Provides SRS functionality and staff, financial, and other resources to more than adequately meet the technical needs of this TLD, and;
- Manages the SRS with a team of experienced technical professionals who can seamlessly integrate this TLD into the Afilias registry platform and support the TLD in a secure, stable and reliable manner


A. Description of operation of the SRS, including diagrams

Afilias’ SRS provides the same advanced functionality as that used in the “.INFO” and “.ORG” registries, as well as the fourteen other TLDs currently supported by Afilias. The Afilias registry system is standards-compliant and utilizes proven technology, ensuring global familiarity for registrars, and it is protected by our massively provisioned infrastructure that mitigates the risk of disaster.

EPP functionality is described fully in our response to question #25; please consider those answers incorporated here by reference. An abbreviated list of Afilias SRS functionality includes:

- Domain registration: Afilias provides registration of names in the TLD, in both ASCII and IDN forms, to accredited registrars via EPP and a web-based administration tool
- Domain renewal: Afilias provides services that allow registrars the ability to renew domains under sponsorship at any time. Further, the registry performs the automated renewal of all domain names at the expiration of their term, and allows registrars to rescind automatic renewals within a specified number of days after the transaction for a full refund
- Transfer: Afilias provides efficient and automated procedures to facilitate the transfer of sponsorship of a domain name between accredited registrars. Further, the registry enables bulk transfers of domains under the provisions of the Registry-Registrar Agreement
- RGP and restoring deleted domain registrations: Afilias provides support for the Redemption Grace Period (RGP) as needed, enabling the restoration of deleted registrations
- Other grace periods and conformance with ICANN guidelines: Afilias provides support for other grace periods that are evolving as standard practice inside the ICANN community. In addition, the Afilias registry system supports the evolving ICANN guidelines on IDNs

Afilias also supports the basic check, delete, and modify commands.

As required for all new gTLDs, Afilias provides “thick” registry system functionality. In this model, all key contact details for each domain are stored in the registry. This allows better access to domain data and provides uniformity in storing the information.

Afilias’ SRS complies today and will continue to comply with global best practices including relevant RFCs, ICANN requirements, and this TLD’s respective domain policies. With over a decade of experience, Afilias has fully documented and tested policies and procedures, and our highly skilled team members are active participants of the major relevant technology and standards organizations, so ICANN can be assured that SRS performance and compliance are met. Full details regarding the SRS system and network architecture are provided in responses to questions #31 and #32; please consider those answers incorporated here by reference.

A.1 SRS servers and software

All applications and databases for this TLD will run in a virtual environment currently hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors. (It is possible that by the time this application is evaluated and systems deployed, Westmere processors may no longer be the “latest”; the Afilias policy is to use the most advanced, stable technology available at the time of deployment.) The data for the registry will be stored on storage arrays of solid state drives shared over a fast storage area network. The virtual environment allows the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It also facilitates effective utilization of system resources, thus reducing energy consumption and carbon footprint.

The network firewalls, routers and switches support all applications and servers. Hardware traffic shapers are used to enforce an equitable access policy for connections coming from registrars. The registry system accommodates both IPv4 and IPv6 addresses. Hardware load balancers accelerate TLS⁄SSL handshaking and distribute load among a pool of application servers.

Each of the servers and network devices are equipped with redundant, hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with a four-hour response time at all our data centers guarantee replacement of failed parts in the shortest time possible.

Examples of current system and network devices used are:

- Servers: Cisco UCS B230 blade servers
- SAN storage arrays: IBM Storwize V7000 with Solid State Drives
- SAN switches: Brocade 5100
- Firewalls: Cisco ASA 5585-X
- Load balancers: F5 Big-IP 6900
- Traffic shapers: Procera PacketLogic PL8720
- Routers: Juniper MX40 3D
- Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232

These system components are upgraded and updated as required, and have usage and performance thresholds which trigger upgrade review points. In each data center, there is a minimum of two of each network component, a minimum of 25 servers, and a minimum of two storage arrays.

Technical components of the SRS include the following items, continually checked and upgraded as needed: SRS, WHOIS, web admin tool, DNS, DNS distributor, reporting, invoicing tools, and deferred revenue system (as needed).

All hardware is massively provisioned to ensure stability under all forecast volumes from launch through “normal” operations of average daily and peak capacities. Each and every system application, server, storage and network device is continuously monitored by the Afilias Network Operations Center for performance and availability. The data gathered is used by dynamic predictive analysis tools in real-time to raise alerts for unusual resource demands. Should any volumes exceed established thresholds, a capacity planning review is instituted which will address the need for additions well in advance of their actual need.


B. SRS diagram and interconnectivity description

As with all core registry services, the SRS is run from a global cluster of registry system data centers, located in geographic centers with high Internet bandwidth, power, redundancy and availability. All of the registry systems will be run in a 〈n+1〉 setup, with a primary data center and a secondary data center. For detailed site information, please see our responses to questions #32 and #35. Registrars access the SRS in real-time using EPP.

A sample of the Afilias SRS technical and operational capabilities (displayed in Figure 24-a) include:

- Geographically diverse redundant registry systems;
- Load balancing implemented for all registry services (e.g. EPP, WHOIS, web admin) ensuring equal experience for all customers and easy horizontal scalability;
- Disaster Recovery Point objective for the registry is within one minute of the loss of the primary system;
- Detailed and tested contingency plan, in case of primary site failure, and;
- Daily reports, with secure access for confidentiality protection

As evidenced in Figure 24-a, the SRS contains several components of the registry system. The interconnectivity ensures near-real-time distribution of the data throughout the registry infrastructure, timely backups, and up-to-date billing information.

The WHOIS servers are directly connected to the registry database and provide real-time responses to queries using the most up-to-date information present in the registry.

Committed DNS-related EPP objects in the database are made available to the DNS Distributor via a dedicated set of connections. The DNS Distributor extracts committed DNS-related EPP objects in real time and immediately inserts them into the zone for dissemination.

The Afilias system is architected such that read-only database connections are executed on database replicas and connections to the database master (where write-access is executed) are carefully protected to ensure high availability.

This interconnectivity is monitored, as is the entire registry system, according to the plans detailed in our response to question #42.


C. Synchronization scheme

Registry databases are synchronized both within the same data center and in the backup data center using a database application called Slony. For further details, please see the responses to questions #33 and #37. Slony replication of transactions from the publisher (master) database to its subscribers (replicas) works continuously to ensure the publisher and its subscribers remain synchronized. When the publisher database completes a transaction the Slony replication system ensures that each replica also processes the transaction. When there are no transactions to process, Slony “sleeps” until a transaction arrives or for one minute, whichever comes first. Slony “wakes up” each minute to confirm with the publisher that there has not been a transaction and thus ensures subscribers are synchronized and the replication time lag is minimized. The typical replication time lag between the publisher and subscribers depends on the topology of the replication cluster, specifically the location of the subscribers relative to the publisher. Subscribers located in the same data center as the publisher are typically updated within a couple of seconds, and subscribers located in a secondary data center are typically updated in less than ten seconds. This ensures real-time or near-real-time synchronization between all databases, and in the case where the secondary data center needs to be activated, it can be done with minimal disruption to registrars.


D. SRS SLA performance compliance

Afilias has a ten-year record of delivering on the demanding ICANN SLAs, and will continue to provide secure, stable and reliable service in compliance with SLA requirements as specified in the new gTLD Registry Agreement, Specification 10, as presented in Figure 24-b.

The Afilias SRS currently handles over 200 million EPP transactions per month for just “.INFO” and “.ORG.” Overall, the Afilias SRS manages over 700 million EPP transactions per month for all TLDs under management.

Given this robust functionality, and more than a decade of experience supporting a thick TLD registry with a strong performance history, Afilias, on behalf of Merck KgaA, will meet or exceed the performance metrics in Specification 10 of the new gTLD Registry Agreement. The Afilias services and infrastructure are designed to scale both vertically and horizontally without any downtime to provide consistent performance as this TLD grows. The Afilias architecture is also massively provisioned to meet seasonal demands and marketing campaigns. Afilias’ experience also gives high confidence in the ability to scale and grow registry operations for this TLD in a secure, stable and reliable manner.


E. SRS resourcing plans

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

Over 100 Afilias team members contribute to the management of the SRS code and network that will support this TLD. The SRS team is composed of Software Engineers, Quality Assurance Analysts, Application Administrators, System Administrators, Storage Administrators, Network Administrators, Database Administrators, and Security Analysts located at three geographically separate Afilias facilities. The systems and services set up and administered by these team members are monitored 24x7 by skilled analysts at two NOCs located in Toronto, Ontario (Canada) and Horsham, Pennsylvania (USA). In addition to these team members, Afilias also utilizes trained project management staff to maintain various calendars, work breakdown schedules, utilization and resource schedules and other tools to support the technical and management staff. It is this team who will both deploy this TLD on the Afilias infrastructure, and maintain it. Together, the Afilias team has managed 11 registry transitions and six new TLD launches, which illustrate its ability to securely and reliably deliver regularly scheduled updates as well as a secure, stable and reliable SRS service for this TLD.


F. Attachments

24_figures.pdf - Sample of the Afilias SRS technical and operational capabilities

25. Extensible Provisioning Protocol (EPP)

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS.  HENCE, THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE AS INTENDED.  THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.


Answers for this question (#25) are provided by Afilias, the back-end provider of registry services for this TLD.

Afilias has been a pioneer and innovator in the use of EPP. “.INFO” was the first EPP-based gTLD registry and launched on EPP version 02⁄00. Afilias has a track record of supporting TLDs on standards-compliant versions of EPP. Afilias will operate the EPP registrar interface as well as a web-based interface for this TLD in accordance with RFCs and global best practices. In addition, Afilias will maintain a proper OT&E (Operational Testing and Evaluation) environment to facilitate registrar system development and testing.

Afilias’ EPP technical performance meets or exceeds all ICANN requirements as demonstrated by:

- A completely functional, state-of-the-art, EPP-based SRS that currently meets the needs of various gTLDs and will meet this new TLD’s needs;
- A track record of success in developing extensions to meet client and registrar business requirements such as multi-script support for IDNs;
- Supporting six ICANN gTLDs on EPP: “.INFO,” “.ORG,” “.MOBI,” “.AERO,” “.ASIA” and “.XXX”
- EPP software that is operating today and has been fully tested to be standards-compliant;
- Proven interoperability of existing EPP software with ICANN-accredited registrars, and;
- An SRS that currently processes over 200 million EPP transactions per month for both “.INFO” and “.ORG.” Overall, Afilias processes over 700 million EPP transactions per month for all 16 TLDs under management

The EPP service is offered in accordance with the performance specifications defined in the new gTLD Registry Agreement, Specification 10.


A. EPP Standards

The Afilias registry system complies with the following revised versions of the RFCs and operates multiple ICANN TLDs on these standards, including “.INFO,” “.ORG,” “.MOBI,” “.ASIA” and “.XXX.” The systems have been tested by our Quality Assurance (“QA”) team for RFC compliance, and have been used by registrars for an extended period of time:

- 3735 - Guidelines for Extending EPP
- 3915 - Domain Registry Grace Period Mapping
- 5730 - Extensible Provisioning Protocol (EPP)
- 5731 - Domain Name Mapping
- 5732 - Host Mapping
- 5733 - Contact Mapping
- 5734 - Transport Over TCP
- 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

This TLD will support all valid EPP commands. The following EPP commands are in operation today and will be made available for this TLD. See attachment #25a for the base set of EPP commands and copies of Afilias XSD schema files, which define all the rules of valid, RFC compliant EPP commands and responses that Afilias supports. Any customized EPP extensions, if necessary, will also conform to relevant RFCs.

Afilias staff members actively participated in the Internet Engineering Task Force (IETF) process that finalized the new standards for EPP. Afilias will continue to actively participate in the IETF and will stay abreast of any updates to the EPP standards.


B. EPP software interface and functionality

Afilias will provide all registrars with a free open-source EPP toolkit. Afilias provides this software for use with both Microsoft Windows and Unix⁄Linux operating systems. This software, which includes all relevant templates and schema defined in the RFCs, is available on sourceforge.net and will be available through the registry operator’s website.

Afilias’ SRS EPP software complies with all relevant RFCs and includes the following functionality:

- EPP Greeting: A response to a successful connection returns a greeting to the client. Information exchanged can include: name of server, server date and time in UTC, server features, e.g., protocol versions supported, languages for the text response supported, and one or more elements which identify the objects that the server is capable of managing;
- Session management controls: 〈login〉 to establish a connection with a server, and 〈logout〉 to end a session;
- EPP Objects: Domain, Host and Contact for respective mapping functions;
- EPP Object Query Commands: Info, Check, and Transfer (query) commands to retrieve object information, and;
- EPP Object Transform Commands: five commands to transform objects: 〈create〉 to create an instance of an object, 〈delete〉 to remove an instance of an object, 〈renew〉 to extend the validity period of an object, 〈update〉 to change information associated with an object, and 〈transfer〉 to manage changes in client sponsorship of a known object

Currently, 100% of the top domain name registrars in the world have software that has already been tested and certified to be compatible with the Afilias SRS registry. In total, over 375 registrars, representing over 95% of all registration volume worldwide, operate software that has been certified compatible with the Afilias SRS registry. Afilias’ EPP Registrar Acceptance Criteria are available in attachment #25b, EPP OT&E Criteria.

B.1 Free EPP software support

Afilias analyzes and diagnoses registrar EPP activity log files as needed and is available to assist registrars who may require technical guidance regarding how to fix repetitive errors or exceptions caused by misconfigured client software.

Registrars are responsible for acquiring a TLS⁄SSL certificate from an approved certificate authority, as the registry-registrar communication channel requires mutual authentication; Afilias will acquire and maintain the server-side TLS⁄SSL certificate. The registrar is responsible for developing support for TLS⁄SSL in their client application. Afilias will provide free guidance for registrars unfamiliar with this requirement.


C. Registrar data synchronization

There are two methods available for registrars to synchronize their data with the registry:

- Automated synchronization: Registrars can, at any time, use the EPP 〈info〉 command to obtain definitive data from the registry for a known object, including domains, hosts (nameservers) and contacts
- Personalized synchronization: A registrar may contact technical support and request a data file containing all domains (and associated host (nameserver) and contact information) registered by that registrar, within a specified time interval. The data will be formatted as a comma separated values (CSV) file and made available for download using a secure server


D. EPP modifications

There are no unique EPP modifications planned for this TLD.

All ICANN TLDs must offer a Sunrise as part of a rights protection program. Afilias uses EPP extensions that allow registrars to submit trademark and other intellectual property rights (IPR) data to the registry. These extensions are:

- An 〈ipr:name〉 element that indicates the name of Registered Mark.
- An 〈ipr:number〉 element that indicates the registration number of the IPR
- An 〈ipr:ccLocality〉 element that indicates the origin for which the IPR is established (a national or international trademark registry).
- An 〈ipr:entitlement〉 element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”
- An 〈ipr:appDate〉 element that indicates the date the Registered Mark was applied for
- An 〈ipr:regDate〉 element that indicates the date the Registered Mark was issued and registered
- An 〈ipr:class〉 element that indicates the class of the registered mark
- An 〈ipr:type〉 element that indicates the Sunrise phase the application applies for

Note that some of these extensions might be subject to change based on ICANN-developed requirements for the Trademark Clearinghouse.


E. EPP resourcing plans

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

108 Afilias team members directly contribute to the management and development of the EPP based registry systems. As previously noted, Afilias is an active member of IETF and has a long documented history developing and enhancing EPP. These contributors include 11 developers and 14 QA engineers focused on maintaining and enhancing EPP server side software. These engineers work directly with business staff to timely address existing needs and forecast registry⁄registrar needs to ensure the Afilias EPP software is effective today and into the future. A team of eight data analysts work with the EPP software system to ensure that the data flowing through EPP is securely and reliably stored in replicated database systems. In addition to the EPP developers, QA engineers, and data analysts, other EPP contributors at Afilias include: Technical Analysts, the Network Operations Center and Data Services team members.


F. Attachments

25a_XML_Request_Response.pdf - Base set of EPP commands and copies of Afilias XSD schema files
25b-Info_EPP_RFC_OTE_criteria_v1-6-1 - EPP OT&E Criteria

26. Whois

Answers for this question (#26) are provided by Afilias, the back-end provider of registry services for this TLD.

Afilias operates the WHOIS (registration data directory service) infrastructure in accordance with RFCs and global best practices, as it does for the 16 TLDs it currently supports. Designed to be robust and scalable, Afilias’ WHOIS service has exceeded all contractual requirements for over a decade. It has extended search capabilities, and methods of limiting abuse.

The WHOIS service operated by Afilias meets and exceeds ICANN’s requirements. Specifically, Afilias will:

- Offer a WHOIS service made available on port 43 that is flexible and standards- compliant;
- Comply with all ICANN policies, and meeting or exceeding WHOIS performance requirements in Specification 10 of the new gTLD Registry Agreement;
- Enable a Searchable WHOIS with extensive search capabilities that offers ease of use while enforcing measures to mitigate access abuse, and;
- Employ a team with significant experience managing a compliant WHOIS service

Such extensive knowledge and experience managing a WHOIS service enables Afilias to offer a comprehensive plan for this TLD that meets the needs of constituents of the domain name industry and Internet users. The service has been tested by our QA team for RFC compliance, and has been used by registrars and many other parties for an extended period of time. Afilias’ WHOIS service currently serves almost 500 million WHOIS queries per month, with the capacity already built in to handle an order of magnitude increase in WHOIS queries, and the ability to smoothly scale should greater growth be needed.


A. WHOIS system description and diagram

The Afilias WHOIS system, depicted in figure 26-a, is designed with robustness, availability, compliance, and performance in mind. Additionally, the system has provisions for detecting abusive usage (e.g., excessive numbers of queries from one source). The WHOIS system is generally intended as a publicly available single object lookup system. Afilias uses an advanced, persistent caching system to ensure extremely fast query response times.

Afilias will develop restricted WHOIS functions based on specific domain policy and regulatory requirements as needed for operating the business (as long as they are standards compliant). It will also be possible for contact and registrant information to be returned according to regulatory requirements. The WHOIS database supports multiple string and field searching through a reliable, free, secure web-based interface.


A.1 Data objects, interfaces, access and lookups

Registrars can provide an input form on their public websites through which a visitor is able to perform WHOIS queries. The registry operator can also provide a Web-based search on its site. The input form must accept the string to query, along with the necessary input elements to select the object type and interpretation controls. This input form sends its data to the Afilias port 43 WHOIS server. The results from the WHOIS query are returned by the server and displayed in the visitor’s Web browser. The sole purpose of the Web interface is to provide a user-friendly interface for WHOIS queries.

Afilias will provide WHOIS output as per Specification 4 of the new gTLD Registry Agreement. The output for domain records generally consists of the following elements:

- The name of the domain registered and the sponsoring registrar;
- The names of the primary and secondary nameserver(s) for the registered domain name;
- The creation date, registration status and expiration date of the registration;
- The name, postal address, e-mail address, and telephone and fax numbers of the domain name holder;
- The name, postal address, e-mail address, and telephone and fax numbers of the technical contact for the domain name holder;
- The name, postal address, e-mail address, and telephone and fax numbers of the administrative contact for the domain name holder, and;
- The name, postal address, e-mail address, and telephone and fax numbers of the billing contact for the domain name holder

The following additional features are also present in Afilias’ WHOIS service:

- Support for IDNs, including the language tag and the Punycode representation of the IDN in addition to Unicode Hex and Unicode HTML formats;
- Enhanced support for privacy protection relative to the display of confidential information

Afilias will also provide sophisticated WHOIS search functionality that includes the ability to conduct multiple string and field searches.

A.2 Query controls

For all WHOIS queries, a user is required to enter the character string representing the information for which they want to search. The object type and interpretation control parameters to limit the search may also be specified. If object type or interpretation control parameter is not specified, WHOIS will search for the character string in the Name field of the Domain object.

WHOIS queries are required to be either an ʺexact searchʺ or a ʺpartial search,ʺ both of which are insensitive to the case of the input string.

An exact search specifies the full string to search for in the database field. An exact match between the input string and the field value is required.

A partial search specifies the start of the string to search for in the database field. Every record with a search field that starts with the input string is considered a match. By default, if multiple matches are found for a query, then a summary containing up to 50 matching results is presented. A second query is required to retrieve the specific details of one of the matching records.

If only a single match is found, then full details will be provided. Full detail consists of the data in the matching object as well as the data in any associated objects. For example: a query that results in a domain object includes the data from the associated host and contact objects.

WHOIS query controls fall into two categories: those that specify the type of field, and those that modify the interpretation of the input or determine the level of output to provide. Each is described below.

The following keywords restrict a search to a specific object type:

- Domain: Searches only domain objects. The input string is searched in the Name field
- Host: Searches only nameserver objects. The input string is searched in the Name field and the IP Address field
- Contact: Searches only contact objects. The input string is searched in the ID field
- Registrar: Searches only registrar objects. The input string is searched in the Name field
By default, if no object type control is specified, then the Name field of the Domain object is searched

In addition, Afilias WHOIS systems can perform and respond to WHOIS searches by registrant name, postal address and contact names. Deployment of these features is provided as an option to the registry operator, based upon registry policy and business decision making.

Figure 26-b presents the keywords that modify the interpretation of the input or determine the level of output to provide.

By default, if no interpretation control keywords are used, the output will include full details if a single match is found and a summary if multiple matches are found.

A.3 Unique TLD requirements

There are no unique WHOIS requirements for this TLD.

A.4 Sunrise WHOIS processes

All ICANN TLDs must offer a Sunrise as part of a rights protection program. Afilias uses EPP extensions that allow registrars to submit trademark and other intellectual property rights (IPR) data to the registry. The following corresponding data will be displayed in WHOIS for relevant domains:

- Trademark Name: element that indicates the name of the Registered Mark
- Trademark Number: element that indicates the registration number of the IPR
- Trademark Locality: element that indicates the origin for which the IPR is established (a national or international trademark registry).
- Trademark Entitlement: element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”
- Trademark Application Date: element that indicates the date the Registered Mark was applied for
- Trademark Registration Date: element that indicates the date the Registered Mark was issued and registered
- Trademark Class: element that indicates the class of the Registered Mark
- IPR Type: element that indicates the Sunrise phase the application applies for


B. IT and infrastructure resources

All the applications and databases for this TLD will run in a virtual environment hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors (or a more advanced, stable technology available at the time of deployment). The registry data will be stored on storage arrays of solid-state drives shared over a fast storage area network. The virtual environment allows the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It also facilitates effective utilization of system resources thus reducing energy consumption and carbon footprint.

The applications and servers are supported by network firewalls, routers and switches.

The WHOIS system accommodates both IPv4 and IPv6 addresses.

Each of the servers and network devices are equipped with redundant hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with our hardware vendor with a 4-hour response time at all our data centers guarantees replacement of failed parts in the shortest time possible.

Models of system and network devices used are:

- Servers: Cisco UCS B230 blade servers
- SAN storage arrays: IBM Storwize V7000 with Solid State Drives
- Firewalls: Cisco ASA 5585-X
- Load balancers: F5 Big-IP 6900
- Traffic shapers: Procera PacketLogic PL8720
- Routers: Juniper MX40 3D
- Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232

There will be at least four virtual machines (VMs) offering WHOIS service. Each VM will run at least two WHOIS server instances - one for registrars and one for the public. All instances of the WHOIS service is made available to registrars and the public are rate limited to mitigate abusive behavior.


C. Frequency of synchronization between servers

Registration data records from the EPP publisher database will be replicated to the WHOIS system database on a near-real-time basis whenever an update occurs.


D. Specifications 4 and 10 compliance

The WHOIS service for this TLD will meet or exceed the performance requirements in the new gTLD Registry Agreement, Specification 10. Figure 26-c provides the exact measurements and commitments. Afilias has a 10 year track record of exceeding WHOIS performance and a skilled team to ensure this continues for all TLDs under management.

The WHOIS service for this TLD will meet or exceed the requirements in the new gTLD Registry Agreement, Specification 4.


E. RFC 3912 compliance

Afilias will operate the WHOIS infrastructure in compliance with RFCs and global best practices, as it does with the 16 TLDs Afilias currently supports.

Afilias maintains a registry-level centralized WHOIS database that contains information for every registered domain and for all host and contact objects. The WHOIS service will be available on the Internet standard WHOIS port (port 43) in compliance with RFC 3912. The WHOIS service contains data submitted by registrars during the registration process. Changes made to the data by a registrant are submitted to Afilias by the registrar and are reflected in the WHOIS database and service in near-real-time, by the instance running at the primary data center, and in under ten seconds by the instance running at the secondary data center, thus providing all interested parties with up-to-date information for every domain. This service is compliant with the new gTLD Registry Agreement, Specification 4.

The WHOIS service maintained by Afilias will be authoritative and complete, as this will be a “thick” registry (detailed domain contact WHOIS is all held at the registry); users do not have to query different registrars for WHOIS information, as there is one central WHOIS system. Additionally, visibility of different types of data is configurable to meet the registry operator’s needs.


F. Searchable WHOIS

Afilias offers a searchable WHOIS on a web-based Directory Service. Partial match capabilities are offered on the following fields: domain name, registrar ID, and IP address. In addition, Afilias WHOIS systems can perform and respond to WHOIS searches by registrant name, postal address and contact names.

Providing the ability to search important and high-value fields such as registrant name, address and contact names increases the probability of abusive behavior. An abusive user could script a set of queries to the WHOIS service and access contact data in order to create or sell a list of names and addresses of registrants in this TLD. Making the WHOIS machine readable, while preventing harvesting and mining of WHOIS data, is a key requirement integrated into the Afilias WHOIS systems. For instance, Afilias limits search returns to 50 records at a time. If bulk queries were ever necessary (e.g., to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process), Afilias makes such query responses available to carefully screened and limited staff members at the registry operator (and customer support staff) via an internal data warehouse. The Afilias WHOIS system accommodates anonymous access as well as pre-identified and profile-defined uses, with full audit and log capabilities.

The WHOIS service has the ability to tag query responses with labels such as “Do not redistribute” or “Special access granted”. This may allow for tiered response and reply scenarios. Further, the WHOIS service is configurable in parameters and fields returned, which allow for flexibility in compliance with various jurisdictions, regulations or laws.

Afilias offers exact-match capabilities on the following fields: registrar ID, nameserver name, and nameserver’s IP address (only applies to IP addresses stored by the registry, i.e., glue records). Search capabilities are fully available, and results include domain names matching the search criteria (including IDN variants). Afilias manages abuse prevention through rate limiting and CAPTCHA (described below). Queries do not require specialized transformations of internationalized domain names or internationalized data fields

Please see “Query Controls” above for details about search options and capabilities.


G. Deterring WHOIS abuse

Afilias has adopted two best practices to prevent abuse of the WHOIS service: rate limiting and CAPTCHA.

Abuse of WHOIS services on port 43 and via the Web is subject to an automated rate-limiting system. This ensures that uniformity of service to users is unaffected by a few parties whose activities abuse or otherwise might threaten to overload the WHOIS system.

Abuse of web-based public WHOIS services is subject to the use of CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) technology. The use of CAPTCHA ensures that uniformity of service to users is unaffected by a few parties whose activities abuse or otherwise might threaten to overload the WHOIS system. The registry operator will adopt a CAPTCHA on its Web-based WHOIS.

Data mining of any sort on the WHOIS system is strictly prohibited, and this prohibition is published in WHOIS output and in terms of service.

For rate limiting on IPv4, there are configurable limits per IP and subnet. For IPv6, the traditional limitations do not apply. Whenever a unique IPv6 IP address exceeds the limit of WHOIS queries per minute, the same rate-limit for the given 64 bits of network prefix that the offending IPv6 IP address falls into will be applied. At the same time, a timer will start and rate-limit validation logic will identify if there are any other IPv6 address within the original 80-bit(⁄48) prefix. If another offending IPv6 address does fall into the ⁄48 prefix then rate-limit validation logic will penalize any other IPv6 addresses that fall into that given 80-bit (⁄48) network. As a security precaution, Afilias will not disclose these limits.

Pre-identified and profile-driven role access allows greater granularity and configurability in both access to the WHOIS service, and in volume⁄frequency of responses returned for queries.

Afilias staff are key participants in the ICANN Security & Stability Advisory Committee’s deliberations and outputs on WHOIS, including SAC003, SAC027, SAC033, SAC037, SAC040, and SAC051. Afilias staff are active participants in both technical and policy decision making in ICANN, aimed at restricting abusive behavior.


H. WHOIS staff resourcing plans

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

Within Afilias, there are 11 staff members who develop and maintain the compliant WHOIS systems. They keep pace with access requirements, thwart abuse, and continually develop software. Of these resources, approximately two staffers are typically required for WHOIS-related code customization. Other resources provide quality assurance, and operations personnel maintain the WHOIS system itself. This team will be responsible for the implementation and on-going maintenance of the new TLD WHOIS service.


I. Attachments

26-figures.pdf - Afilias WHOIS system

27. Registration Life Cycle

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS.  HENCE, THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE AS INTENDED.  THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.


Answers for this question (#27) are provided by Afilias, the back-end provider of registry services for this TLD.

Afilias has been managing registrations for over a decade. Afilias has had experience managing registrations for over a decade and supports comprehensive registration lifecycle services including the registration states, all standard grace periods, and can address any modifications required with the introduction of any new ICANN policies.

This TLD will follow the ICANN standard domain lifecycle, as is currently implemented in TLDs such as “.ORG” and “.INFO.” The below response includes: a diagram and description of the lifecycle of a domain name in this TLD, including domain creation, transfer protocols, grace period implementation and the respective time frames for each; and the existing resources to support the complete lifecycle of a domain.

As depicted in Figure 27-a, prior to the beginning of the Trademark Claims Service or Sunrise IP protection program[s], Afilias will support the reservation of names in accordance with the new gTLD Registry Agreement, Specification 5.


A. Registration period

After the IP protection programs and the general launch, eligible registrants may choose an accredited registrar to register a domain name. The registrar will check availability on the requested domain name and if available, will collect specific objects such as, the required contact and host information from the registrant. The registrar will then provision the information into the registry system using standard Extensible Provisioning Protocol (“EPP”) commands through a secure connection to the registry backend service provider.

When the domain is created, the standard five day Add Grace Period begins, the domain and contact information are available in WHOIS, and normal operating EPP domain statuses will apply. Other specifics regarding registration rules for an active domain include:

- The domain must be unique;
- Restricted or reserved domains cannot be registered;
- The domain can be registered from 1-10 years;
- The domain can be renewed at any time for 1-10 years, but cannot exceed 10 years;
- The domain can be explicitly deleted at any time;
- The domain can be transferred from one registrar to another except during the first 60 days following a successful registration or within 60 days following a transfer; and,
- Contacts and hosts can be modified at any time

The following describe the domain status values recognized in WHOIS when using the EPP protocol following RFC 5731.

- OK or Active: This is the normal status for a domain that has no pending operations or restrictions.
- Inactive: The domain has no delegated name servers.
- Locked: No action can be taken on the domain. The domain cannot be renewed, transferred, updated, or deleted. No objects such as contacts or hosts can be associated to, or disassociated from the domain. This status includes: Delete Prohibited ⁄ Server Delete Prohibited, Update Prohibited ⁄ Server Update Prohibited, Transfer Prohibited, Server Transfer Prohibited, Renew Prohibited, Server Renew Prohibited.
- Hold: The domain will not be included in the zone. This status includes: Client Hold, Server Hold.
- Transfer Prohibited: The domain cannot be transferred away from the sponsoring registrar. This status includes: Client Transfer Prohibited, Server Transfer Prohibited.

The following describe the registration operations that apply to the domain name during the registration period.

A.1 Domain modifications:

This operation allows for modifications or updates to the domain attributes to include:

- Registrant Contact
- Admin Contact
- Technical Contact
- Billing Contact
- Host or nameservers
- Authorization information
- Associated status values

A domain with the EPP status of Client Update Prohibited or Server Update Prohibited may not be modified until the status is removed.

A.2 Domain renewals

This operation extends the registration period of a domain by changing the expiration date. The following rules apply:

i. A domain can be renewed at any time during its registration term,
ii. The registration term cannot exceed a total of 10 years.

A domain with the EPP status of Client Renew Prohibited or Server Renew Prohibited cannot be renewed.

A.3 Domain deletions

This operation deletes the domain from the Shared Registry Services (SRS). The following rules apply:

- A domain can be deleted at any time during its registration term, f the domain is deleted during the Add Grace Period or the Renew⁄Extend Grace Period, the sponsoring registrar will receive a credit,
- A domain cannot be deleted if it has “child” nameservers that are associated to other domains

A domain with the EPP status of Client Delete Prohibited or Server Delete Prohibited cannot be deleted.

A.4 Domain transfers

A transfer of the domain from one registrar to another is conducted by following the steps below.

- The registrant must obtain the applicable 〈authInfo〉 code from the sponsoring (losing) registrar
- Every domain name has an authInfo code as per EPP RFC 5731. The authInfo code is a six- to 16-character code assigned by the registrar at the time the name was created. Its purpose is to aid identification of the domain owner so proper authority can be established (it is the ʺpasswordʺ to the domain)
- Under the Registry-Registrar Agreement, registrars will be required to provide a copy of the authInfo code to the domain registrant upon his or her request
- The registrant must provide the authInfo code to the new (gaining) registrar, who will then initiate a domain transfer request. A transfer cannot be initiated without the authInfo code
- Every EPP 〈transfer〉 command must contain the authInfo code or the request will fail. The authInfo code represents authority to the registry to initiate a transfer

iii. Upon receipt of a valid transfer request, the registry automatically asks the sponsoring (losing) registrar to approve the request within five calendar days

- When a registry receives a transfer request the domain cannot be modified, renewed or deleted until the request has been processed. This status must not be combined with either Client Transfer Prohibited or Server Transfer Prohibited status
- If the sponsoring (losing) registrar rejects the transfer within five days, the transfer request is cancelled. A new domain transfer request will be required to reinitiate the process
- If the sponsoring (losing) registrar does not approve or reject the transfer within five days, the registry automatically approves the request
- After a successful transfer, it is strongly recommended that registrars change the authInfo code, so that the prior registrar or registrant cannot use it anymore
- Registrars must retain all transaction identifiers and codes associated with successful domain object transfers and protect them from disclosure
- Once a domain is successfully transferred the status of TRANSFERPERIOD is added to the domain for a period of five days
- Successful transfers will result in a one year term extension (resulting in a maximum total of 10 years), which will be charged to the gaining registrar

A.5 Bulk transfer

Afilias, supports bulk transfer functionality within the SRS for situations where ICANN may request the registry to perform a transfer of some or all registered objects (includes domain, contact and host objects) from one registrar to another registrar. Once a bulk transfer has been executed, expiry dates for all domain objects remain the same, and all relevant states of each object type are preserved. In some cases the gaining and the losing registrar as well as the registry must approved bulk transfers. A detailed log is captured for each bulk transfer process and is archived for audit purposes.
Merck KgaA will support ICANN’s Transfer Dispute Resolution Process. Merck KgaA will work with Afilias to respond to Requests for Enforcement (law enforcement or court orders) and will follow that process.


B. Auto-renew grace period

The Auto-Renew Grace Period displays as AUTORENEWPERIOD in WHOIS. An auto-renew must be requested by the registrant through the sponsoring registrar and occurs if a domain name registration is not explicitly renewed or deleted by the expiration date and is set to a maximum of 45 calendar days. In this circumstance the registration will be automatically renewed by the registry system the first day after the expiration date. If a Delete, Extend, or Transfer occurs within the AUTORENEWPERIOD the following rules apply:

- Delete. If a domain is deleted the sponsoring registrar at the time of the deletion receives a credit for the auto-renew fee. The domain then moves into the Redemption Grace Period with a status of PENDING DELETE RESTORABLE
- Renew⁄Extend. A domain can be renewed as long as the total term does not exceed 10 years. The account of the sponsoring registrar at the time of the extension will be charged for the additional number of years the registration is renewed
- Transfer (other than ICANN-approved bulk transfer). If a domain is transferred, the losing registrar is credited for the auto-renew fee, and the year added by the operation is cancelled. As a result of the transfer, the expiration date of the domain is extended by minimum of one year as long as the total term does not exceed 10 years. The gaining registrar is charged for the additional transfer year(s) even in cases where a full year is not added because of the maximum 10 year registration restriction


C. Redemption grace period

During this period, a domain name is placed in the PENDING DELETE RESTORABLE status when a registrar requests the deletion of a domain that is not within the Add Grace Period. A domain can remain in this state for up to 30 days and will not be included in the zone file. The only action a registrar can take on a domain is to request that it be restored. Any other registrar requests to modify or otherwise update the domain will be rejected. If the domain is restored it moves into PENDING RESTORE and then OK. After 30 days if the domain is not restored it moves into PENDING DELETE SCHEDULED FOR RELEASE before the domain is released back into the pool of available domains.


D. Pending delete

During this period, a domain name is placed in PENDING DELETE SCHEDULED FOR RELEASE status for five days, and all Internet services associated with the domain will remain disabled and domain cannot be restored. After five days the domain is released back into the pool of available domains.


E. Other grace periods

All ICANN required grace periods will be implemented in the registry backend service provider’s system including the Add Grace Period (AGP), Renew⁄Extend Grace Period (EGP), Transfer Grace Period (TGP), Auto-Renew Grace Period (ARGP), and Redemption Grace Period (RGP). The lengths of grace periods are configurable in the registry system. At this time, the grace periods will be implemented following other gTLDs such as “.ORG.” More than one of these grace periods may be in effect at any one time. The following are accompanying grace periods to the registration lifecycle.


F. Add grace period

The Add Grace Period displays as ADDPERIOD in WHOIS and is set to five calendar days following the initial registration of a domain. If the domain is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration. If a Delete, Renew⁄Extend, or Transfer operation occurs within the five calendar days, the following rules apply.

- Delete. If a domain is deleted within this period the sponsoring registrar at the time of the deletion is credited for the amount of the registration. The domain is deleted from the registry backend service provider’s database and is released back into the pool of available domains
- Renew⁄Extend. If the domain is renewed within this period and then deleted, the sponsoring registrar will receive a credit for both the registration and the extended amounts. The account of the sponsoring registrar at the time of the renewal will be charged for the initial registration plus the number of years the registration is extended. The expiration date of the domain registration is extended by that number of years as long as the total term does not exceed 10 years
- Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of the ICANN Policy on Transfer of Registrations between registrars may not occur during the ADDPERIOD or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the registrar sponsoring the domain name registration and is enforced by the SRS


G. Renew ⁄ extend grace period

The Renew ⁄ Extend Grace Period displays as RENEWPERIOD in WHOIS and is set to five calendar days following an explicit renewal on the domain by the registrar. If a Delete, Extend, or Transfer occurs within the five calendar days, the following rules apply:

- Delete. If a domain is deleted within this period the sponsoring registrar at the time of the deletion receives a credit for the renewal fee. The domain then moves into the Redemption Grace Period
- Renew⁄Extend. A domain registration can be renewed within this period as long as the total term does not exceed 10 years. The account of the sponsoring registrar at the time of the extension will be charged for the additional number of years the registration is renewed
- Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Renew⁄Extend Grace Period, there is no credit to the losing registrar for the renewal fee. As a result of the transfer, the expiration date of the domain registration is extended by a minimum of one year as long as the total term for the domain does not exceed 10 years

If a domain is auto-renewed, then extended, and then deleted within the Renew⁄Extend Grace Period, the registrar will be credited for any auto-renew fee charged and the number of years for the extension. The years that were added to the domain’s expiration as a result of the auto-renewal and extension are removed. The deleted domain is moved to the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.


H. Transfer Grace Period

The Transfer Grace period displays as TRANSFERPERIOD in WHOIS and is set to five calendar days after the successful transfer of domain name registration from one registrar to another registrar. Transfers under Part A of the ICANN Policy on Transfer of Registrations between registrars may not occur during the TRANSFERPERIOD or within the first 60 days after the transfer. If a Delete or Renew⁄Extend occurs within that five calendar days, the following rules apply:

- Delete. If the domain is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer. The domain then moves into the Redemption Grace Period with a status of PENDING DELETE RESTORABLE
- Renew⁄Extend. If a domain registration is renewed within the Transfer Grace Period, there is no credit for the transfer. The registrarʹs account will be charged for the number of years the registration is renewed. The expiration date of the domain registration is extended by the renewal years as long as the total term does not exceed 10 years


I. Registration lifecycle resources

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way. Virtually all Afilias resource are involved in the registration lifecycle of domains.

There are a few areas where registry staff devote resources to registration lifecycle issues:

- Supporting Registrar Transfer Disputes. The registry operator will have a compliance staffer handle these disputes as they arise; they are very rare in the existing gTLDs
- Afilias has its development and quality assurance departments on hand to modify the grace period functionality as needed, if ICANN issues new Consensus Policies or the RFCs change

Afilias has more than 30 staff members in these departments.


J. Attachments

27_figures.pdf

28. Abuse Prevention and Mitigation

The Registry Operator, Merck KGaA, working with Afilias, will take the requisite operational and technical steps to promote WHOIS data accuracy, limit domain abuse, remove outdated and inaccurate data, and other security measures to ensure the integrity of the “.MERCK” Top-Level Domain (“TLD”). The specific measures include, but are not limited to:

- Posting a TLD Anti-Abuse Policy that clearly defines abuse, and provide point-of-contact information for reporting suspected abuse;
- Committing to rapid identification and resolution of abuse, including suspensions;
- Ensuring completeness of WHOIS information at the time of registration;
- Publishing and maintaining procedures for removing orphan glue records for names removed from the zone; and,
- Establishing measures to deter WHOIS abuse, including rate-limiting, determining data syntax validity, and implementing and enforcing requirements from the Registry-Registrar Agreement


A. Abuse policy

The Anti-Abuse Policy stated below will be enacted under the contractual authority of the registry operator through the Registry-Registrar Agreement, and the obligations will be passed on to and made binding upon registrants. This policy will be posted on the TLD web site along with contact information for registrants or users to report suspected abuse.

The policy is designed to address the malicious use of domain names. The registry operator and its registrars will make reasonable attempts to limit significant harm to Internet users. This policy is not intended to take the place of the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is not to burden law-abiding or innocent registrants and domain users; rather, the intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity.

The below policy is a recent version of the policy that has been used by the “.INFO” registry since 2008, and the “.ORG” registry since 2009. It has proven to be an effective and flexible tool, and Merck KGaA anticipates adopting it in connection with the new “.MERCK” TLD.

A.1 “.MERCK” Anti-Abuse Policy

The following Anti-Abuse Policy is effective upon launch of the TLD. Malicious use of domain names will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general. The registry operator definition of abusive use of a domain includes, without limitation, the following:

- Illegal or fraudulent actions;
- Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums;
- Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;
- Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through, but not limited to, DNS (Domain Name System) hijacking or poisoning;
- Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and Trojan horses;
- Malicious fast-flux hosting: Use of fast-flux techniques with a botnet to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities;
- Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct distributed denial-of-service attacks (DDoS attacks);
- Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). This also includes any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity)

Pursuant to the Registry-Registrar Agreement, the Registry Operator reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, or (5) to correct mistakes made by registry operator or any registrar in connection with a domain name registration. The Registry Operator also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute.

The policy stated above will be accompanied by notes about how to submit a report to the Registry Operator’s abuse point of contact, and how to report an orphan glue record suspected of being used in connection with malicious conduct (see below).


B. Abuse point of contact and procedures for handling abuse complaints

The Registry Operator will establish an abuse point of contact. This contact will be a role-based e-mail address of the form “abuse@registry.merck”. This e-mail address will allow multiple staff members to monitor abuse reports on a 24x7 basis, and then work toward closure of cases as each situation calls for. This role-based approach has been used successfully by ISPs, e-mail service providers, and registrars for many years, and is considered a global best practice.

The Registry Operator’s designated abuse handlers will then evaluate complaints received via the abuse system address. They will decide whether a particular issue is of concern, and decide what action, if any, is appropriate. A tracking ticket will be generated which will be used to track the report internally at the Registry Operator, and will also be provided to the reporter for reference and potential follow-up.

In general, the Registry Operator will find itself receiving abuse reports from a wide variety of parties, including security researchers and Internet security companies, financial institutions such as banks, ordinary Internet users, and law enforcement agencies among others. Some of these parties may provide good forensic data or supporting evidence of the malicious behavior. In other cases, the party reporting an issue may not be familiar with how to provide such data or proof of malicious behavior. It is expected that a percentage of abuse reports to the registry operator will not be actionable, because there will not be enough evidence to support the complaint (even after investigation), and because some reports or reporters will simply not be credible.

Assessing abuse reports requires great care, and the Registry Operator will rely upon professional, trained investigators who are versed in such matters. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants.

Different types of malicious activities require different methods of investigation and documentation. Further, the Registry Operator expects to face unexpected or complex situations that call for professional advice, and will rely upon professional, trained investigators as needed.

In general, there are two types of domain abuse that must be addressed:

- Compromised domains. These domains have been hacked or otherwise compromised by criminals, and the registrant is not responsible for the malicious activity taking place on the domain. For example, the majority of domain names that host phishing sites are compromised. The goal in such cases is to get word to the registrant (usually via the registrar) that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner. Ideally such domains do not get suspended, since suspension would disrupt legitimate activity on the domain
- Malicious registrations. These domains are registered by malefactors for the purpose of abuse. Such domains are generally targets for suspension, since they have no legitimate use

The standard procedure is that the Registry Operator will forward a credible alleged case of malicious domain name use to the domain’s sponsoring registrar with a request that the registrar investigate the case and act appropriately. The registrar will be provided evidence collected as a result of the investigation conducted by the trained abuse handlers. The registrar is the party with a direct relationship with—and a direct contract with—the registrant. The registrar will also have vital information that the Registry Operator will not, such as:

- Details about the domain purchase, such as the payment method used (credit card, PayPal, etc.);
- The identity of a proxy-protected registrant;
- The purchaser’s IP address;
- Whether there is a reseller involved; and,
- The registrant’s past sales history and purchases in other TLDs (insofar as the registrar can determine this)

Registrars do not share the above information with Registry Operators due to privacy and liability concerns, among others. Because they have more information with which to continue the investigation, and because they have a direct relationship with the registrant, the registrar is in the best position to evaluate alleged abuse. The registrar can determine if the use violates the registrar’s legal terms of service or the registry Anti-Abuse Policy, and can decide whether or not to take any action. While the language and terms vary, registrars will be expected to include language in their registrar-registrant contracts that indemnifies the registrar if it takes action, and allows the registrar to suspend or cancel a domain name; this will be in addition to the registry Anti-Abuse Policy. Generally, registrars can act if the registrant violates the registrar’s terms of service, or violates ICANN policy, or if illegal activity is involved, or if the use violates the registry’s Anti-Abuse Policy.

If a registrar does not take action within a time period indicated by the Registry Operator (usually 24 hours), the Registry Operator might then decide to take action itself. At all times, the Registry Operator reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.

When valid court orders or seizure warrants are received from courts or law enforcement agencies of relevant jurisdiction, the registry operator will order execution in an expedited fashion. Compliance with these will be a top priority and will be completed as soon as possible.

The Registry Operator may also engage in proactive screening of its zone for malicious use of the domains in the TLD, and report problems to the sponsoring registrars. The Registry Operator could take advantage of a combination of the following resources, among others:

- Blocklists of domain names and nameservers published by organizations such as SURBL and Spamhaus
- Anti-phishing feeds, which will provide URLs of compromised and maliciously registered domains being used for phishing
- Analysis of registration or DNS query data [DNS query data received by the TLD nameservers]

The Registry Operator will keep records and track metrics regarding abuse and abuse reports. These will include:

- Number of abuse reports received by the registry’s abuse point of contact described above;
- Number of cases and domains referred to registrars for resolution;
- Number of cases and domains where the registry took direct action;
- Resolution times;
- Number of domains in the TLD that have been blacklisted by major anti-spam blocklist providers; and,
- Phishing site uptimes in the TLD

Law enforcement is only expected to be involved in a miniscule percentage of e-crime cases, due to the large number of such incidents worldwide, the limited resources available to the authorities, and the difficulties of investigating and prosecuting across jurisdictions. The Registry Operator will be prepared to call upon relevant law enforcement bodies as needed.


C. Removal of orphan glue records

By definition, orphan glue records used to be glue records. Glue records are related to delegations and are necessary to guide iterative resolvers to delegated nameservers. A glue record becomes an orphan when its parent nameserver record is removed without also removing the corresponding glue record. (Please reference the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.) Orphan glue records may be created when a domain (example.tld) is placed on EPP ServerHold or ClientHold status. When placed on Hold, the domain is removed from the zone and will stop resolving. However, any child nameservers (now orphan glue) of that domain (e.g., ns1.example.tld) are left in the zone. It is important to keep these orphan glue records in the zone so that any innocent sites using that nameserver will continue to resolve. This use of Hold status is an essential tool for suspending malicious domains.

Afilias observes the following procedures, which are being followed by other registries and are generally accepted as DNS best practices. Afilias believes these procedures are also in keeping with ICANN SSAC recommendations.

When a request to delete a domain is received from a registrar, the registry first checks for the existence of glue records. If glue records exist, the registry will check to see if other domains in the registry are using the glue records. If other domains in the registry are using the glue records then the request to delete the domain will fail until no other domains are using the glue records. If no other domains in the registry are using the glue records then the glue records will be removed before the request to delete the domain is satisfied. If no glue records exist then the request to delete the domain will be satisfied.

If a registrar cannot delete a domain because of the existence of glue records that are being used by other domains, then the registrar may refer to the zone file or the “weekly domain hosted by nameserver report” to find out which domains are using the nameserver in question and attempt to contact the corresponding registrar to request that they stop using the nameserver in the glue record. The registry operator does not plan on performing mass updates of the associated DNS records.

The registry operator will accept, evaluate, and respond appropriately to complaints that orphan glue is being used maliciously. Such reports should be made in writing to the registry operator, and may be submitted to the registry’s abuse point-of-contact. If it is confirmed that an orphan glue record is being used in connection with malicious conduct, the registry operator will have the orphan glue record removed from the zone file. Afilias has the technical ability to execute such requests as needed.


D. Methods to promote WHOIS accuracy

The creation and maintenance of accurate WHOIS records is an important part of registry management. As described in the response to Question #26, WHOIS, the Registry Operator will manage a secure, robust and searchable WHOIS service for this TLD.

D.1 WHOIS data accuracy

The Registry Operator will offer a “thick” registry system. In this model, all key contact details for each domain name will be stored in a central location by the registry. This allows better access to domain data, and provides uniformity in storing the information. The Registry Operator will ensure that the required fields for WHOIS data (as per the defined policies for the TLD) are enforced at the registry level. This ensures that the registrars are providing required domain registration data. Fields defined by the registry policy to be mandatory, are documented as such and must be submitted by registrars. The Afilias registry system verifies formats for relevant individual data fields (e.g. e-mail, and phone⁄fax numbers). Only valid country codes are allowed as defined by the ISO 3166 code list.


D.2 Role of registrars

As part of the RRA (Registry Registrar Agreement), the registry operator will require the registrar to be responsible for ensuring the input of accurate WHOIS data by their registrants. The Registrar⁄Registered Name Holder Agreement will include a specific clause to ensure accuracy of WHOIS data, and to give the registrar rights to cancel or suspend registrations if the Registered Name Holder fails to respond to the registrar’s query regarding accuracy of data. ICANN’s WHOIS Data Problem Reporting System (WDPRS) will be available to those who wish to file WHOIS inaccuracy reports, as per ICANN policy (http:⁄⁄wdprs.internic.net⁄

D.3 Privacy services

In order to promote transparency and accuracy within the WhoIs records for the space, privacy registration services shall not be permitted within the “.MERCK” TLD.


E. Controls to ensure proper access to domain functions

Several measures are in place in the Afilias registry system to ensure proper access to domain functions, including authentication provisions in the RRA relative to notification and contact updates via use of AUTH-INFO codes.

IP address access control lists, TLS⁄SSL certificates and proper authentication are used to control access to the registry system. Registrars are only given access to perform operations on the objects they sponsor.

Every domain will have a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time the name is created. Its purpose is to aid identification of the domain owner so proper authority can be established. It is the ʺpasswordʺ to the domain name. Registrars must use the domain’s password in order to initiate a registrar-to-registrar transfer. It is used to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the proper registrant, and that this registrant is adequately notified of domain update activity. Only the sponsoring registrar of a domain has access to the domain’s AUTH-INFO code stored in the registry, and this is accessible only via encrypted, password-protected channels.

Information about other registry security measures such as encryption and security of registrar channels are confidential to ensure the security of the registry system. The details can be found in the response to Question #30b.

As “.MERCK” will constitute a community-based TLD, it is of paramount importance that the Registry Operator’s eligibility and registration restrictions are enforced by registrars. Accordingly, compliance with the Registration Restrictions and Use Policy for the “.MERCK” space, outlined above in the answer to Question 20(e) and provided in full below, will be required of all registrars offering “.MERCK” domain names via the Registry-Registrar Agreement.


F. Registration Approval System

The Registry Operator, Merck KGaA, will maintain the “.MERCK” space on behalf of the Merck Community, and the companies in the Merck Community will be the sole registrants of domain names within the TLD. Prior to registration of any domain name in “.MERCK,” the Corporate Trademark Department of Merck KGaA will review and approve each applied-for second-level domain name string, to ensure that it will further the goals of the Merck Community.

Registration of a “.MERCK” domain name will involve three steps: Approval of the Registrant, Approval of the Domain Name, and Registration. After Registration, the holder of a “.MERCK” domain name must comply with the Acceptable Use Guidelines located in Section P of the “.MERCK” Registration Restrictions and Use Policy. The “.MERCK” Registration Restrictions and Use Policy will be incorporated contractually, through registrar compliance with the Registry-Registrar Agreement, into every Registration Agreement for domain names in the TLD.

F.1 Step 1 – Approval of the Community Member

Each Registrant must be recognized as member of the Merck Community as defined above under Question 18(a). Upon receiving a request from a potential registrant, the Corporate Trademark Department at Merck KGaA will perform an eligibility assessment, to determine whether the applicant qualifies as a member of the Merck Community. This process will include an application form that the prospective member must fill out, and verification of the applicant’s identity by Merck KGaA. If successful, such assessment will be concluded by assigning a ʺMerck Community Membership IDʺ to the new member. Once a member has obtained a Merck Community Membership ID, the member is entitled to register domain names within the “.MERCK” TLD that have been approved by the Corporate Trademark Department of Merck KGaA.

The member approval step needs to be performed only once for each member⁄registrant. The member’s Merck Community Membership ID is a permanent assignment, and will remain the same for all of that member’s domain name registrations.

F.2 Step 2 - Approval of the Second-Level-Domain by the Corporate Trademark Department of Merck KGaA

Before registering a domain name, each member must ask the Corporate Trademark Department of Merck KGaA for approval of the second-level string text. A domain name within the “.MERCK” TLD must:

- further the mission and purpose of the Merck Community;
- not violate or contribute to the violation of the intellectual property rights or other rights of any other party; and
- comply with any applicable laws, government rules or requirements

If the Corporate Trademark Department of Merck KGaA determines that the requested second-level domain name meets the above requirements, it will consent to such registration by the Community Member. The applicant will receive written notification from the Corporate Trademark Department, either consenting to or rejecting the domain request. Such notification will either take the form of an Approval Statement or a Rejection Statement, depending on Merck KGaA’s assessment.

F.3 Step 3 - Registration

When a second-level string request has been approved by the Corporate Trademark Department of Merck KGaA, a prospective registrant may contact an ICANN-accredited registrar to register the approved second-level string and pay the registration fee. The Merck Community Membership ID can be reused for multiple registrations by the same Registrant, and must be provided in the domain Create attempt submitted into the registry by the registrar. Create attempts that are not accompanied by a valid Community Membership I.D. will be automatically rejected by the registry system.

Once the domain Create request has been received at the registry, the domain record will be placed on a “Pending Create” status. This status includes an EPP ServerHold status, placed on the domain record so that the domain cannot resolve. The Registry Operator will then have the opportunity to view the pending domain name, and will be able to either approve the “Pending Create” (thus releasing the Hold status and enabling the Registrant to use the requested domain, or to reject the Create (which will delete the Registrant’s application for the domain name). The Merck KGaA legal team that reviews membership applications and approves domain strings will review all of the Pending Creates, and will compare those pending Creates will the membership and approved string data in its files.

This procedure will ensure that only qualified members of the Community can register domain names in the TLD, and that only approved domains can be used.

Merck KGaA, as the Registry Operator for “.MERCK,” and Afilias Limited have developed the necessary mechanism by which the Merck Community Membership ID and domain name registration authorization systems will function, in order to ensure that the process will operate smoothly and easily for all concerned actors, including for the domain name registrars.

F.4 Additional Notes Regarding Compliance

Registrants of “.MERCK” domain names will agree to the applicable gTLD Registration Agreement provided by the concerned registrar, in addition to the specific terms and conditions set out for the “.MERCK” space. Such additional terms and conditions shall, inter alia, incorporate the Registration Restrictions and Use Policy applicable to “.MERCK,” as well as the applicable dispute resolution mechanisms. Further information concerning the Acceptable Use provisions is outlined below.

The registrations and use of all registered “.MERCK” domain names will be monitored by Merck KGaA on an ongoing basis, and compliance with the contractual restrictions and guidelines will be enforced. Violations of any restrictions, guidelines or other contractual conditions may result in termination of the relevant domain name registration or, in appropriate circumstances, the revocation of the Merck Community Membership ID. As the Registry Operator, authorized Merck KGaA personnel will have access to registry system that will allow them to suspend domain names and revoke membership credentials as needed.

In order to reduce redundancy within the Application, for additional information please refer to the relevant text of the “.MERCK” Registration Restrictions and Use Policy below, and as discussed above in the answer to Question 20(e).

The identities of Registrants will be public, available via the WHOIS.


G. Validation and abuse mitigation mechanisms

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the Registry Operator based on their policy and business needs.

Afilias has the ability to analyze the registration data for known patterns at the time of registration. A database of these known patterns is developed from domains and other associated objects (e.g., contact information) which have been previously detected and suspended after being flagged as abusive. Any domains matching the defined criteria can be flagged for investigation by the domain anti-abuse team members. Once analyzed and confirmed, these domains may be suspended. This provides proactive detection of abusive domains.

Provisions are available to enable the registry operator to only allow registrations by pre-authorized contacts. These verified contacts are given a unique code (the Merck Community Membership ID) which can be used for registration of new domains. As indicated above, each individual registration request for a second-level “.MERCK” domain name will be subject to approval by the Registry Operator, as Merck KGaA will have the opportunity to review (and either accept or reject) each “Pending Create” application for a domain within the TLD space.


H. Registrant pre-verification and authentication

One of the systems that could be used for validity and identity authentication is VAULT (Validation and Authentication Universal Lookup). It utilizes information obtained from a series of trusted data sources with access to billions of records containing data about individuals for the purpose of providing independent age and id verification as well as the ability to incorporate additional public or private data sources as required. At present it has the following: US Residential Coverage - 90% of Adult Population and also International Coverage - Varies from Country to Country with a minimum of 80% coverage (24 countries, mostly European).

Various verification elements can be used. Examples might include applicant data such as name, address, phone, etc. Multiple methods could be used for verification include integrated solutions utilizing API (XML Application Programming Interface) or sending batches of requests.

- Verification and Authentication requirements would be based on TLD operator requirements or specific criteria
- Based on required WHOIS Data; registrant contact details (name, address, phone)
- If address⁄ZIP can be validated by VAULT, the validation process can continue (N. America +25 International countries)
- If in-line processing and registration and EPP⁄API call would go to the verification clearinghouse and return up to 4 challenge questions
- If two-step registration is required, then registrants would get a link to complete the verification at a separate time. The link could be specific to a domain registration and pre-populated with data about the registrant
- If Whois data is validated a token would be generated and could be given back to the registrar which registered the domain
- Whois data would reflect the Validated Data or some subset, i.e., fields displayed could be first initial and last name, country of registrant and date validated. Other fields could be generic validation fields much like a “privacy service”
- A “Validation Icon” customized script would be sent to the registrants email address. This could be displayed on the website and would be dynamically generated to avoid unauthorized use of the Icon. When clicked on the Icon would should limited WHOIS details i.e. Registrant: jdoe, Country: USA, Date Validated: March 29, 2011, as well as legal disclaimers
- Validation would be annually renewed, and validation date displayed in the WHOIS


I. Abuse prevention resourcing plans

The Registry Operator, Merck KGaA, will maintain resources to:

- Evaluate incoming reports to the abuse point of contact, and either act upon them or refer them to registrars as per the above-described procedures
- Evaluate incoming reports from other sources and either act upon them or refer them to registrars as per the above-described procedures
- Analyze the registry and TLD DNS zone activity for malicious and suspicious activity and either act upon them or refer them to registrars as per the above-described procedures

These resources may be a combination of internal staff and outside specialty contractors, who can provide the registry operator with extra expertise when needed. In any case, these responders will be specially trained in the investigation of abuse complaints, and will have the latitude to act expeditiously to suspend domain names (or apply other remedies) when called for.

Abuse prevention and detection is a function that is staffed across the various groups inside Afilias, and requires a team effort when abuse is either well hidden or widespread, or both. All of Afilias’ 200+ employees are charged with responsibility to report any detected abuse. The engineering and analysis teams, numbering over 30, provide specific support based on the type of abuse and volume and frequency of analysis required. The Afilias security and support teams have the authority to initiate mitigation.

I.1 Community-Specific enforcement

Pursuant to the terms of the Registration Restrictions and Use Policy for “.MERCK,” which will be incorporated in the Registration Agreement for each domain name in the space, the Registry Operator expressly reserves the authority to cancel, transfer or otherwise modify any domain name registration within the TLD, if it determines that such domain name has not been registered or used within the requirements of the Policy. As the “.MERCK” space will be managed by Merck KGaA on behalf of, and for the collective good of, the Merck Community, registrants shall accept and agree (through this Policy) that Merck KGaA will have such authority necessary to maintain the TLD for the benefit of the Community at large.


J. Full-Text Version of the “.MERCK” Registration Restrictions and Use Policy

The registration eligibility criteria and acceptable use guidelines for the “.MERCK” TLD are detailed in the “.MERCK” Domain Name Registration Restrictions and Use Policy, provided here for reference.


K. DRAFT “.MERCK” Domain Name Registration Restrictions and Use Policy

K.1 General principles

K.1.1 Merck Community and Role of Merck KGaA

The “.MERCK” domain is a community based Top Level Domain (ʺTLDʺ) established by and for the use Merck KGaA and the the companies of the Merck Group (the “Merck Community”). Merck KGaA, the Registry Operator of the “.MERCK” TLD, is the parent company of the Merck Group. As such, Merck KGaA is responsible for managing the “.MERCK” domain in the interests of the Merck Community. Merck KGaA will, with the advice and assistance of the Registry Service Provider Afilias Ltd., members of the Merck Community, and relevant governmental bodies, develop, maintain and enforce this “.MERCK” Domain Name Registration and Use Policy (the “Policy”).

This Policy is intended to be updated and revised regularly to reflect the needs of the Merck Community. The current version of this Policy will be made publicly available at: [insert website when determined ].

The registration of domain names within the “.MERCK” TLD is restricted to the companies of the “Merck Community”, which are defined as follows:

- the company is Merck KGaA or a company which is a fully owned subsidiary of Merck KGaA,
- the company uses “Merck” as the sole element or as a component of its company name, and
- the company uses as its umbrella brand the German figurative trademark No. 30130670, “MERCK”


Merck KGaA keeps an up-to-date, comprehensive list of the members of the Merck Community at all times.

K.1.2 Policy structure

The “.MERCK” domain is designed to allocate domain name registrations to members of the Merck Community. Only members of the Merck Community, as defined in Section K.1.1 above, may register domain names within the “.MERCK” TLD.

This policy defines the rules of eligibility and process for “.MERCK” domain name allocation, as well as the Acceptable Use guidelines which registrants in the “.MERCK” space agree to abide by. It also sets out the dispute resolution procedures applicable to the “.MERCK” TLD.

K.1.3 Registration process

Registration of a “.MERCK” domain name is done in 3 steps: Identification of the Registrant, Approval of the Domain Name, and Registration. After Registration, the holder of a “.MERCK” domain name must comply with the Acceptable Use Guidelines (see below).

K.1.3.1 Step 1 – Approval of the Community member

Each Registrant must be recognized as member of the Merck Community. This eligibility check shall be performed by the Corporate Trademark Department at Merck KGaA (as described in Section K.2 of this document, ʺEligibility Requirementsʺ) and is concluded by the assignment of a ʺMerck Community Membership IDʺ. Once a Registrant has obtained a Merck Community Membership ID, the Member is entitled to register domain names within the “.MERCK” TLD which have been approved by the Corporate Trademark Department of Merck KGaA.

The Identification step needs to be performed only once by each Registrant. The Registrant’s Merck Community Membership ID is a permanent assignment, and will remain the same for all of that Registrant’s domain name registrations. Should the Registrant desire to register a second-level domain name, or domain names, within the “.MERCK” space, the Registrant must contact the Corporate Trademark Department of Merck KGaA to receive an Approval Statement, authorizing to Registrant to apply for its desired second-level domain name string(s).

K.1.3.2 Step 2 - Approval of the Second-Level-Domain by the Corporate Trademark Department of Merck KGaA

Before registering a domain name each Registrant must ask the Corporate Trademark Department for approval of the second-level string text, on the basis that the registration of such domain name within the “.MERCK” TLD:

- furthers the mission and purpose of the Merck Community;
- does not violate or contribute to the violation of the intellectual property rights or other rights of any other party; and
- complies with any applicable laws, government rules or requirements

If the Corporate Trademark Department of Merck KGaA determines that the requested second-level domain name registration meets the above requirements, it will consent to such registration by the Registrant Community Member. The Registrant will receive a Decision from the Corporate Trademark Department of Merck KGaA, stating either its consent to the registration of the requested domain name, or rejection of the Registrant’s request for approval. Such notification will either take the form of an Approval Statement or a Rejection Statement, depending on Merck KGaA’s assessment.

K.1.3.3 Step 3 - Registration

Where a second-level string request has been approved by the Corporate Trademark Department of Merck KGaA, the Member may contact an ICANN-accredited registrar to apply for the registration of the specified second-level string and pay the registration fee. The Merck Community Membership ID can be reused for multiple registrations by the same Member, and must be provided in the application materials submitted to the concerned registrar.

Successful domain requests will be placed into a “Pending Create” status. A “Server Hold” will be placed on the new domain name to ensure that it does not resolve. The Registry Operator will then have the opportunity to view the applied-for, pending domain name, verify the string applied for, and will be able to either approve the “Pending Create” (thus releasing the Hold status and enabling the Registrant to use the requested domain), or to reject the domain.

K.2 Eligibility Requirements

To be recognized as a member of the Merck Community, a Registrant must meet the Eligibility Requirements, which are as follows:

- the Registrant is Merck KGaA or a company which is a fully owned subsidiary of Merck KGaA,
- the Registrant uses “Merck” as the sole element or as a component of its company name, and
- the Registrant uses as its umbrella brand the German figurative trademark No. 30130670, “MERCK”

Once its eligibility is established, the Registrant will receive a Merck Community Membership ID (via mail, email or fax) that it will use to identify itself when registering a “.MERCK” domain name. Merck KGaA and the Registry Service Provider will design and implement the necessary mechanisms for this identification and eligibility assessment process. A Registrant may apply directly to the Corporate Trademark Department of Merck KGaA to receive a Merck Community Membership ID.

After a prospective Registrant has applied for a Merck Community Membership ID, the Corporate Trademark Department of Merck KGaA shall review the request and determine whether or not the Registrant meets the eligibility standards for inclusion in the Merck Community. If Merck KGaA determines that the prospective Registrant is, in fact, a member of the Merck Community, the Corporate Trademark Department of Merck KGaA will issue a Merck Community Membership ID. If Merck KGaA determines that the prospective registrant is not a member of the Merck Community, and declines to issue a Merck Community Membership ID, the prospective applicant may pursue a review of this decision through the “.MERCK” Eligibility and Functionality Reconsideration Policy, discussed further below under the section entitled “Dispute Resolution”.

Once its eligibility is established, the Registrant will receive a Merck Community Membership ID (via mail, email or fax) that it will use to identify itself when registering any “.MERCK” domain name.

Following the assignment of a Merck Community Membership ID, the Registrant can view and update information associated with its Merck Community Membership ID online at [website to be determined].

K.2.1 Application for a Merck Community Membership ID

Any prospective Registrant must request a Merck Community Membership ID from Merck KGaA prior to submitting a domain registration request. Such request for a Merck Community Membership ID must:

- provide information regarding the Registrantʹs identity;
- provide relevant evidence demonstrating the Registrant’s qualification as a member of the Merck Community

By submitting the request for a Merck Community Membership ID, the Registrant:

- Warrants that it is a member of the Merck Community and meets the eligibility requirements set out in this Policy;
- Agrees to the terms set out in this Policy;
- Declares that the information provided in the application is complete and correct;
- Acknowledges that the issue of the Merck Community Membership ID is subject to verification and audit by Merck KGaA and agrees that when required by Merck KGaA, it will supply supporting documents to allow Merck KGaA to verify the credentials and other information in the application, including in connection with ongoing monitoring activities

Merck KGaA may request any necessary additional information from the Registrant in order to evaluate the Registrant’s request for a Merck Community Membership ID.

K.3 Domain Allocation Rules

K.3.1 String Requirements and Reserved Names

Second-Level Domain names within the TLD must only include hyphens in the third and fourth position if they represent valid internationalized domain names in their ASCII encoding (for example ʺxn--ndk061nʺ), and must otherwise comply with any other applicable ICANN requirements.


L. Reserved Names

- The label “EXAMPLE” shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations
- Two-character labels. All two-character labels shall be initially reserved. The reservation of a two-character label string may be released to the extent that Registry Operator reaches agreement with the government and country-code manager. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes
- Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the TLD: NIC, WWW, IRIS and WHOIS
- The List of Reserved Names shall be compiled by Merck KGaA and will be publicly posted online at [website to be determined]. Merck KGaA reserves the right to include new names in the list of reserved names, and to later add names to such list as it deems reasonably necessary for the benefit of the Merck Community


M. Country and Territory Names

The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations:

- 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 ;
- 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 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names; provided, that the reservation of specific country and territory names may be released to the extent that Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN


N. Regulated second-level names within the “.MERCK” TLD

N.1. Format “ANYNAME.MERCK”

N.2. Eligibility

The Registrant is allowed to register any second-level name in the above format, which follows the string requirements and common rules described above and for which the Registrant has been granted an Approval Statement from the Corporate Trademark Department at Merck KGaA, as outlined above in Section K.1.3.2, under Step 2 of the Registration Process.

N.3.Allocation

Domain names will be generally allocated on a ʺfirst come, first servedʺ basis, subject to Merck KGaA’s Corporate Trademark Department’s prior approval that the domain name:

- furthers the mission and purpose of the Merck Community;
- does not infringe any other third parties rights; and
- complies with any applicable laws, government rules or requirements

Merck KGaA does not anticipate there to be multiple applications for a particular domain name. If, however, two registration requests for the same second-level string were to be received by Merck KGaA simultaneously, Merck KGaA would evaluate both requests on the basis of the specified criteria and determine which registrant, if either, should be granted the registration.

Merck KGaA has the authority to make changes to any domain name registration in the “.MERCK” space for the benefit of the Merck Community at large under Section P below.


O. Registration Rules

O.1 Registration period and renewals

A “.MERCK” domain name may be registered, and renewed at the end of each registration period, subject to the current terms and conditions offered by the concerned Registrar.

O.2 Continuing eligibility

If the Registrant ceases to be a member of the Merck Community, then the Registrant’s registered “.MERCK” domain names may be immediately revoked and⁄or transferred at the discretion of Merck KGaA. Additionally, Merck KGaA will undertake ongoing monitoring activities to ensure that all registrants of “.MERCK” domain names remain bona fide members of the Merck Community. Additionally, if a registrant fails to comply with the terms and conditions set out in the “.MERCK” Registration Restrictions and Use Policy, Merck KGaA may in its sole discretion elect to transfer, cancel or revoke any relevant domain name registration(s) held by said registrant.

O.3 Transfer of domain name registrations

A “.MERCK” domain name registration may only be transferred in the following circumstances:

- the company to whom the “.MERCK” domain name is to be transferred to meets the criteria set out in this “.MERCK” Registration Restrictions and Use Policy:

- the prescribed fee is paid; and

- Merck KGaA has previously approved the transfer of the domain name registration from the Transferor to the Transferee

Transfers of a “.MERCK” domain name shall be carried out by the Registrar of the relevant “.MERCK” domain name.

O.4 Revoking a domain name registration

The Registrant agrees with Merck KGaA (the Registry Operator of the “.MERCK” TLD) that Merck KGaA may revoke a Merck Community Membership ID and⁄or the registration of a “.MERCK” domain name for the reasons outlined below:

Change in status
If the Registrant ceases to be a member of the Merck Community.

Fee not paid
If the prescribed fee is not paid within the required time.

Breach of warranty
If a warranty supplied by the Registrant or their agent is breached, including failure to comply with the Acceptable Usage Guidelines contained in this Policy.

Incorrect information
If misleading, incomplete or incorrect information is supplied in the application for either a domain name registration or a Merck Community Membership ID.

Failure to comply with this Policy
If the Registrant fails to comply with this Policy.

Court or arbitration decision
If a court or arbitration panel of competent authority determines that a “.MERCK” domain name should not be registered by the Registrant, it shall be removed from the registry or be registered to another entity.

ADR Decision
If an Alternative Dispute Resolution Panel of competent authority determines that a “.MERCK” domain name should not be registered by the Registrant, it shall be removed from the registry or be registered to another entity.

Improper use
If the Registrant has used its “.MERCK” domain name in violation of the Acceptable Use guidelines provided in Section P below.

Instruction
If instructed by the Registrant.

Error
If a “.MERCK” domain name which could not otherwise be registered under this Policy is registered through mistake.


P. Acceptable Usage Guidelines for “.MERCK” Domain Names

P.1 Acceptable Use

All Registrants agree to abide by the Acceptable Usage Guidelines established herein for the operation and use of their “.MERCK” domain names. Registrants agree that their “.MERCK” domain names shall be used:

- to further the mission and purpose of the Merck Community;
- to display only content related to the Merck Community’s activities; and
- to display only content reasonably related to the textual string of the specific domain name, to enable intuitive navigation by visitors to the “.MERCK” space

Registrants further agree that they shall not use any “.MERCK” domain name in a way that:

- infringes any other third parties rights
- is in breach with any applicable laws, government rules or requirements

or for the purposes of:

- undertaking any illegal or fraudulent actions, including spam or phishing activities,
- defaming Merck KGaA or the Merck Community, its businesses, employees, etc.;
- “parking” the website at a landing page;
- displaying pay-per-click links; or
- “warehousing” or otherwise failing to use the domain name to link to active content


All Registrants agree that the “.MERCK” domain space shall be used for the benefit of the Merck Community at large, and shall cooperate to achieve this common goal. Registrants agree that Merck KGaA, as the Registry Operator of the TLD and parent company of the Merck Group, has the right to revoke any domain name registration or re-allocate any domain name registration to a different Community member should Merck KGaA deem such action appropriate for the benefit of the Community.


Q. Dispute Resolution Policies

Q.1 MERCK Eligibility and Functionality Reconsideration Policy (“MEFRP”)

All Registrants agree to be bound by the “.MERCK” Eligibility and Functionality Reconsideration Policy (“MEFRP”). This Policy serves as a mechanism for reconsideration and shall apply to any challenge by a Registrant to a decision by Merck KGaA (the Registry Operator):

- that the Registrant does not or does no longer meet the “.MERCK” eligibility requirements as described in this Policy, and so is not entitled to a Merck Community Membership ID; or
- that the Registrant’s requested second-level domain name string would not be in the best interests of the Merck Community at large, resulting in the issuance of a Rejection Statement or a rejection of the Registrant’s application for a domain name registration.
- if the Registrant is a holder of a “.MERCK” domain name, to revoke the domain name registration

Full text of the MEFRP is located here: [insert link once available].

Q.2 Charter Eligibility Dispute Resolution Policy (ʺCEDRPʺ)

All Registrants agree to be bound by the Charter Eligibility Dispute Resolution Policy (ʺCEDRPʺ), which applies to challenges on the grounds that a particular Registrant does not meet the eligibility requirements to register its domain name within the “.MERCK” space. The full text of the CEDRP is located here: [http:⁄⁄www.icann.org⁄en⁄help⁄dndr⁄cedrp].

Q.3. Uniform Domain Name Dispute Resolution Policy (ʺUDRPʺ)

All Registrants agree to be bound by the Uniform Domain Name Dispute Resolution Policy (ʺUDRP”), which applies to challenges to registered domain names on the grounds that: 1) such domain names are identical or confusingly similar to a trademark in which the complainant has rights, 2) the registrant lacks rights or legitimate interests in the domain name, and 3) the domain name has been registered and used in bad faith. The full text of the UDRP is located at the following address: http:⁄⁄www.icann.org⁄dndr⁄udrp⁄policy.htm.

Q.4 Uniform Rapid Suspension System (“URS”)

All Registrants agree to be bound by the Uniform Rapid Suspension System (“URS”), which applies to challenges to registered domain names on the grounds that: 1) such domain names are identical or confusingly similar to a trademark in which the complainant has rights, 2) the registrant lacks rights or legitimate interests in the domain name, and 3) the domain name has been registered and used in bad faith. The full text of the URS is located at the following address: [insert website when available].

Q.5 Registry Restrictions Dispute Resolution Procedure (“RRDRP”)

The Registry Operator for “.MERCK” shall agree to be bound by the Registry Restrictions Dispute Resolution Procedure (“RRDRP”). The RRDRP applies to challenges by Merck Community members claiming to be “a harmed established institution” as a result of the community-based gTLD registry operator not complying with the registration restrictions set out in the Registry Agreement. Full text of the RRDRP is located at the following address: insert website when available].

Q.6 Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP)

The Registry Operator for “.MERCK” shall agree to be bound by the Trademark Post-Delegation Dispute Resolution Procedure (“Trademark PDDRP”). The Trademark PDDRP applies to challenges by trademark holders claiming that one or more of its marks have been infringed, and thereby the trademark holder has been harmed, by the registry operator’s manner of operation or use of the gTLD. Full text of the Trademark PDDRP is located at the following address: [insert website when available].


R. Verification of eligibility and domain name registrations

R.1 Verification Process

Merck KGaA shall operate a verification system to prevent the misuse of Merck Community Membership IDs and to ensure that this Policy, including the Acceptable Usage Guidelines of Section P, is complied with. The verification may be conducted by Merck KGaA directly or by a third party appointed by Merck KGaA for this purpose.

If a Registrant is selected for verification, then it may be asked to provide supporting information demonstrating that it meets the eligibility requirements defined in this Policy, that its “.MERCK” domain name registration complies with this Policy, or that the content displayed on the website at its “.MERCK” domain name complies with the Acceptable Usage Guidelines contained in this Policy.

If the Registrant fails to cooperate with a request or fails to cooperate within a reasonable time period, then Merck KGaA may cancel the Merck Community Membership ID and⁄or revoke the registration agreement for the “.MERCK” domain names registered by that Registrant.


S. Warranties

The administration of the “.MERCK” domain relies upon the information and warranties supplied by the Registrant. Accordingly, by applying for a “.MERCK” domain name, the Registrant:

- warrants that the Registrant meets the eligibility requirements set out in this Policy;
- warrants that the Corporate Trademark Department of Merck KGaA has approved the registration of the applied-for domain name;
- warrants that the domain name complies with this Policy;
- warrants that the information provided by the Registrant is complete, true and accurate;
- warrants that the registration and use of the “.MERCK” domain name does not breach any third partyʹs rights (such as those of a registered trademark holder);
- warrants that the operation and use of the “.MERCK” domain name will be undertaken in line with the Acceptable Usage Guidelines contained in this Policy;
- warrants that they have read and understood this Policy, and that they understand that this Policy is legally binding; and
- indemnifies Merck KGaA to the full extent legally permitted against all claims and demands from third parties regarding the registration and use of the “.MERCK” domain name

29. Rights Protection Mechanisms

Rights protection is a core responsibility of the Top-Level Domain (“TLD”) operator, and is supported by a well-developed plan for rights protection that includes:

- Establishing mechanisms to prevent unqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies);
- Implementing a robust Sunrise program, utilizing the Trademark Clearinghouse, the services of one of ICANN’s approved dispute resolution providers, a trademark validation agent, and drawing upon sunrise policies and rules used successfully in previous gTLD launches;
- Implementing a professional trademark claims program that utilizes the Trademark Clearinghouse, and drawing upon models of similar programs used successfully in previous TLD launches;
- Complying with the requirements of the Uniform Rapid Suspension System (“URS”);
- Complying with the Uniform Domain Name Dispute Resolution Policy (“UDRP”);
- Complying with the Registry Restrictions Dispute Resolution Procedure (“RRDRP”);
- Complying with the Trademark Post-Delegation Dispute Resolution Policy (“PDDRP”); and,
- Including all ICANN-mandated and independently developed rights protection mechanisms (“RPMs”) in the registry-registrar agreement entered into by ICANN-accredited registrars authorized to register names in the TLD

The response below details the rights protection mechanisms at the launch of the TLD (Sunrise and Trademark Claims Service) which comply with rights protection policies (URS, UDRP, RRDRP, PDDRP, and other ICANN RPMs), outlines additional provisions made for rights protection, and provides the resourcing plans.


A. Safeguards for rights protection at the launch of the TLD

This TLD will satisfy the rights protection mechanisms described in the New gTLD Registry Agreement.

Merck KGaA will implement a Sunrise period of 30 days for the purpose of complying with ICANN requirements. Because the Registry Operator and the other community members will be the sole registrants within this space, there will be no other registrants eligible to reserve or register domain names during this period.

Notice will be provided to all relevant trademark holders in the Clearinghouse if someone is seeking a Sunrise registration. This notice will be provided to holders of marks in the Clearinghouse that are an Identical Match to the name to be registered during Sunrise.

The Registry Operator will develop and implement an appropriate Sunrise Dispute Resolution Policy (SDRP), containing the elements specified by ICANN, for the resolution of any disputes which might in theory arise during this period. The proposed Sunrise Eligibility Requirements (SERs) will include: (i) ownership of a mark (that satisfies the criteria in section 7.2), (ii) optional registry elected requirements re: international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark. The The proposed SDRP will allow challenges based on the four grounds specified in the New gTLD Registry Agreement: (i) at time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.

The launch of this TLD will include the operation of a trademark claims service according to the defined ICANN processes for checking a registration request and alerting trademark holders of potential rights infringement. The Trademark Claims Service will operate for at least the first 60 days that the registry is open for general registration. We will use the Trademark Claims Notice provided in the Applicant Guidebook, We will provide the prospective registrant access to the Trademark Clearinghouse Database information referenced in the Trademark Claims Notice to enhance understanding of the Trademark rights being claimed by the trademark holder. These links shall be provided in real time without cost to the prospective registrant.


B. Ongoing rights protection mechanisms

Several mechanisms will be in place to protect rights in this TLD. As described in responses #27 and #28, measures are in place to ensure domain transfers and updates are only initiated by the appropriate domain holder, and an experienced team is available to respond to legal actions by law enforcement or court orders.

This TLD will conform to all ICANN RPMs including URS (defined below), UDRP, PDDRP, RRDRP and all measures defined in Specification 7 of the new TLD agreement.

B.1 Uniform Rapid Suspension (URS)

The Registry Operator will implement decisions rendered under the URS on an ongoing basis. Per the URS policy posted on ICANN’s Web site as of this writing, the Registry Operator will receive notice of URS actions from the ICANN-approved URS providers. These emails will be directed immediately to the Registry Operator’s support staff, which is on duty 24x7. The support staff will be responsible for creating a ticket for each case, and for executing the directives from the URS provider. All support staff will receive pertinent training.

As per ICANN’s URS guidelines, within 24 hours of receipt of the notice of complaint from the URS provider, the Registry Operator shall “lock” the domain, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will remain in the TLD DNS zone file and will thus continue to resolve. The support staff will “lock” the domain by associating the following EPP statuses with the domain and relevant contact objects:

- ServerUpdateProhibited, with an EPP reason code of “URS”
- ServerDeleteProhibited, with an EPP reason code of “URS”
- ServerTransferProhibited, with an EPP reason code of “URS”
- The registry operator’s support staff will then notify the URS provider immediately upon locking the domain name, via email

The Registry Operator’s support staff will retain all copies of emails from the URS providers, assign them a tracking or ticket number, and will track the status of each opened URS case through to resolution via spreadsheet or database.

The Registry Operator’s support staff will execute further operations upon notice from the URS providers. The URS provider is required to specify the remedy and required actions of the registry operator, with notification to the registrant, the complainant, and the registrar.

As per the URS guidelines, if the complainant prevails, the “registry operator shall suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS provider about the URS. The WHOIS for the domain name shall continue to display all of the information of the original registrant except for the redirection of the nameservers. In addition, the WHOIS shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.”

B.2 Community TLD considerations

In addition to the above-referenced RPMs (URS, DRP, PDDRP and RRDRP), and the Trademark Clearing House and Sunrise registration periods, the Registry Operator intends to implement two further rights protection mechanisms within the “.MERCK” space. These additional policies, the Charter Eligibility Dispute Resolution Policy (CEDRP) and the “.MERCK” Eligibility and Functionality Reconsideration Policy (ʺMEFRPʺ) are designed address circumstances of unqualified registrations within the space.

As provided in detail above, in sections 18(c), 20(e) and 28, the “.MERCK” space will contain a set of safeguards to ensure that only valid members of the Merck Community may register domain names within the new TLD. These procedures are fully detailed in our response to Question 28. In brief, the process to register a domain name in the space is three-fold, and a brief outline of the process is as follows:

- A prospective applicant must apply to the Corporate Legal Department of Merck KGaA to request a Merck Community Membership ID. A Membership ID is unique to a particular applicant⁄registrant, and therefore this step needs only be performed once by Community Member. When an application to receive a Merck Community Membership ID is received by Merck KGaA, the Registry Operator will evaluate the request and determine whether the prospective registrant qualifies as a member of the Merck Community. If the applicant is a member of the Community, a Merck Community Membership ID will be issued. If not, and no Membership ID is issued, the denied applicant would have recourse to an appeals process under the MEFRP (full text available for reference at the end of this section)
- Once a Merck Community Membership ID has been issued to a member, said member must also receive pre-approval of the particular second-level string or strings which the member would like to register. Again, the request must be submitted to the Corporate Legal Department of Merck KGaA. If Merck determines that the requested domain name registration would serve the purposes, and be in the best interests, of the Merck Community, the Registry Operator will issue a statement of consent to the member for each requested second-level string
- Once a prospective applicant for a “.MERCK” domain name has obtained a Merck Community Membership ID, and pre-approval for the its requested domain name string(s), it may then register the indicated “.MERCK” domain name through any ICANN-accredited registrar. The Registry Operator will then have the opportunity to review each “Pending Create” request for a domain name string to confirm compliance with the above process, and to ensure that all registrations within the space serve the best interests of the Merck Community

Pursuant to its reserved authority in the “.MERCK” Domain Name Registration Restrictions and Use Policy, MerckKGaA shall have the right to cancel, transfer, terminate, or otherwise make changes to any domain name application or registration within the space for the benefit of the Merck Community at large. Merck KGaA will undertake routine monitoring efforts to ensure that all of the websites active within the “.MERCK” space are being used within the guidelines set forward in the Registration Restrictions and Use Policy.

Should any third party believe that a “.MERCK” domain name has been registered by an entity which is not a member of the Merck Community, it may file a CEDRP complaint to have the issue addressed. Likewise, should a prospective applicant for a Merck Community Membership ID believe its application was denied incorrectly, it may appeal the decision under the MEFRP. Any registrant of a “.MERCK” domain name who believes Merck KGaA acts unfairly in cancelling, transferring or otherwise modifying its domain name registration on the basis of non-compliance with the Registration Restrictions and Use Policy for “.MERCK” shall also have recourse to an appeal under the MEFRP. The full text of the MEFRP Policy has been provided below for reference, and the a draft copy of the Registration Restrictions and Use Policy may be found in the answer to Question 28 above.

B.3 Rights protection via the Registry-Registrar and Registrar-Registrant Agreements

The following will be memorialized and be made binding via the Registry-Registrar and Registrar-Registrant Agreements (RRAs):

- The registry may reject a registration request or a reservation request, or may delete, revoke, suspend, cancel, or transfer a registration or reservation under the following criteria:

- to enforce registry policies and ICANN requirements; each as amended from time to time;
- that is not accompanied by complete and accurate information as required by ICANN requirements and⁄or registry policies or where required information is not updated and⁄or corrected as required by ICANN requirements and⁄or registry policies;
- to protect the integrity and stability of the registry, its operations, and the TLD system;
- to comply with any applicable law, regulation, holding, order, or decision issued by a court, administrative authority, or dispute resolution service provider with jurisdiction over the registry;
- to establish, assert, or defend the legal rights of the registry or a third party or to avoid any civil or criminal liability on the part of the registry and⁄or its affiliates, subsidiaries, officers, directors, representatives, employees, contractors, and stockholders;
- to correct mistakes made by the registry or any accredited registrar in connection with a registration; or
- as otherwise provided in the Registry-Registrar Agreement and⁄or the Registrar-Registrant Agreement


C. Reducing opportunities for behaviors such as phishing or pharming

In our response to question #28, the registry operator has described its anti-abuse program designed to address phishing and pharming. This program is designed to actively discover, verify, and mitigate problems without infringing upon the rights of legitimate registrants. This program is designed for use in the open registration period and includes an optional system for monitoring the TLD for phishing attacks and policies and procedures for verifying and mitigating phishing attacks. These procedures include the reporting of compromised Websites⁄domains to registrars for cleanup by the registrants and their hosting providers, and rapid takedown procedures for maliciously registered phishing domains. Additionally, in order reduce the risk of malicious activity no registrations within the space will be permitted through the use of privacy services.

Rather than repeating the policies and procedures here, please see our response to question #28 for full details.

Since all “.MERCK” applicants and domain names will be reviewed and approved, there is an exceptionally low chance that “.MERCK” domain names will be registered by criminals, for purposes such as phishing. There is a chance that the Web sites of innocent “.MERCK” community members may get compromise by criminals, in which case any cases will be reported to the registrar and registrant for mitigation and cleanup.


D. Draft “.MERCK” Eligibility and Functionality Reconsideration Policy (ʺMEFRPʺ)

This Policy is designed to address disputes between you, the Applicant for a Merck Community Membership ID number, the Applicant for a “.MERCK” domain name registration seeking approval from Merck KGaA for a particular second-level domain name within the “.MERCK” space, or the Registrant of a “.MERCK” domain name, and the Registry Operator of the “.MERCK” space. This Policy is incorporated by reference into all applications for Merck Community Membership IDs, requests for domain name Approval Statements, and Registration Agreements for domain name registrations in the “.MERCK” space.

D.1 Purpose

This “.MERCK” Eligibility and Functionality Reconsideration Policy (the ʺPolicyʺ) has been adopted by the Registry Operator and is incorporated by reference into your application for a Merck Community Membership ID and⁄or request for an Approval Statement for a “.MERCK” domain name string, and into any Registration Agreement you may have for a “.MERCK” domain name. It sets out the terms and conditions in connection with any challenge you may wish to make in relation to a Decision by the Registry Operator:

- that you do not or that you no longer meet the “.MERCK” eligibility requirements as described in the Registration Restrictions and Use Policy for “.MERCK” (ʺEligibility Requirementsʺ); or
- that your requested second-level domain name textual string is not in the best interests of the Mercy Community as a whole, or fails to meet the technical requirements for the domain space; or
- if you are the holder of a “.MERCK” domain name, to revoke your domain name registration (ʺrevocationʺ)

Any Challenge brought pursuant to this Policy must be submitted to Merck KGaA within thirty (30) days of the relevant Decision which forms the basis of the Challenge action.

Throughout this document, the terms ʺyouʺ, ʺyourʺ and “the Challenger” refer to the applicant for a Merck Community Membership ID or domain name Approval Statement, or the Registrant of a “.MERCK” domain name, as the case may be. The terms ʺus,ʺ ʺourʺ and ʺweʺ refer to the Registry Operator.

D.2 Your Representations

By applying for a Merck Community Membership ID, an Approval Statement, a “.MERCK” domain name registration, or by asking the Registrar to maintain or renew a domain name registration, you hereby represent and warrant to us that:

- the assertions that you made in your Merck Community Membership ID application, your Approval Statement request, and⁄or your Registration Agreement are complete and accurate;
- you are eligible to register a domain name within the “.MERCK” TLD space;
- to your knowledge, your registration of the requested domain name will not infringe upon or otherwise violate the rights of any third party;
- you are not registering the “.MERCK” domain name for an unlawful purpose, or for any purpose violative of the “.MERCK” Registration Restrictions and Use Policy; and
- you will not knowingly use the domain name in violation of the “.MERCK” Registration Restrictions and Use Policy, or any applicable laws or regulations

It is your responsibility to determine whether your domain name registration infringes or violates someone elseʹs rights.

D.3 Definitions

Approval Statement: A notice issued by Merck KGaA to a prospective Applicant for a “.MERCK” domain name, stating that the Registry Operator consents to the Applicant’s registration of such domain through an accredited Registrar.

Challenge: A Challenge is a request made by and Applicant for reconsideration under the “.MERCK” Eligibility and Functionality Reconsideration Policy of a Decision rendered by the Registry Operator.

Challenger: An applicant or registrant bringing a Challenge under the “.MERCK” Eligibility and Functionality Reconsideration Policy. Any person or entity against whom an adverse Decision has been made by the Registry Operator, with respect to i) a request to receive a Merck Community Membership ID, ii) a request to receive an Approval Statement, or iii) a domain name registration within the “.MERCK” space, may bring a Challenge pursuant to this Policy.

Community Panel: The Community Panel is the three-member panel appointed by the Registry Operator to resolve the Challenge brought pursuant to the “.MERCK” Eligibility and Functionality Reconsideration Policy. The Panel shall consist of one (1) representative of Merck KGaA, and two (2) representatives of members of the Merck Community.

Decision: Any Decision made by the Registry Operator:

- that the Applicant does not meet the Eligibility Requirements set out in the “.MERCK” Registration Restrictions and Use Policy; or
- that the Applicant’s requested second-level string does not in the best interests of the Merck Community; or
- to issue a Rejection Statement, indicating that the Applicant’s request for approval of a particular “.MERCK” domain name string has been rejected by Merck KGaA; or
- to revoke, transfer or otherweise modify the Registrant’s “.MERCK” domain name registration on the grounds that its use of the domain name is contrary to the requirements set forth in the “.MERCK” Registration Restrictions and Use Policy

Finding: This is the decision made by the Community Panel respect to any Challenge brought pursuant to this Policy.

ICANN: The Internet Corporation for Assigned Names and Numbers.

Merck Community Membership ID: A permanently assigned identification number assigned by the TLD Registry Operator to a member of the Merck Community. Such Merck Community Membership ID must be applied for by the Applicant and, once issued, may be used to enable the registration of a “.MERCK” domain name.

Panelist: A member of the Community Panel appointed by the Registry Operator to hear the Challenge.

Party: A Party means the Challenger or the Registry Operator.

Registrar: Any ICANN-accredited registrar who offers “.MERCK” domain names for registration, following the registration mechanism outlined in the “.MERCK” Registration Restrictions and Use Policy and in conjunction with the Registry Service Provider.

Registry Operator: The Registry Operator for the “.MERCK” TLD is Merck KGaA.

Registry Service Provider: The Registry Service Provider for the “.MERCK” TLD shall be Afilias LTD.

Rejection Statement: A notice issued by Merck KGaA to a prospective Applicant for a “.MERCK” domain name, stating that the Registry Operator does not consent to the Applicant’s registration of such domain through an accredited Registrar


D.4 Mandatory Proceeding.

You are required to submit any challenge concerning a Decision by us denying the issuance of a Merck Community Membership ID or Approval Statement, or revocation of your “.MERCK” domain name registration, to a mandatory Challenge proceeding conducted in accordance with this Policy. Any such Challenge will serve as a request for reconsideration, or appeal, of our Decision, and will be decided by a three-member panel consisting of one (1) representative from Merck KGaA, and two (2) representatives from Merck Community members.


D.5 Challenge Procedure

- The Challenger shall submit its Challenge, including any annexes, electronically to the Registry Operator, to the email address: [insert email address when available].

- The Challenge shall:
* Request that the Challenge be submitted for decision in accordance with the Policy and these Rules;
* Confirm that the Challenge is being submitted no later than thirty (30) calendar days from the rendering of the relevant Decision by the Registry Operator;
* Provide the name and electronic contact information of the Challenger and of any representative authorized to act on behalf of the Challenger for this purposes of the proceeding;
- As appropriate for the given Challenge, the Challenger must:
* provide a copy of the rejected Application for a Merck Community Membership ID;
* Provide a copy of the Rejection Statement; or
* specify the domain name(s) that is⁄are the subject of the Challenge
* In the case of a Challenge to a Decision regarding a registered “.MERCK” domain name(s), the Challenger must identify the Registrar(s) with whom the domain name(s) is⁄are registered at the time the Challenge is filed;
- Describe, in accordance with this Policy, the grounds on which the Challenge is made, including, as appropriate:
* why the Challenger believes it should be properly deemed a member of the Merck Community
* why the second-level string applied would, in fact, be in the best interests of the Merck Community and serve the purposes outlined in the “.MERCK” Registration Restrictions and Use Policy; and⁄or
* why the Challenger’s “.MERCK” domain name(s) should be considered as having been used properly in accordance with the “.MERCK” Registration Restrictions and Use Policy
- Specify the remedy sought;
-identify any other legal proceedings, if any, that have been commenced or terminated in connection with or relating to any of the domain name(s) that may be the subject of the Challenge;
- Conclude with the following statement followed by the signature (in any electronic format) of the Challenger or its authorized representative:
* ʺThe Challenger agrees that its claims and remedies concerning the registration of the domain name (if any), the dispute, or the disputeʹs resolution shall be solely against the Registry Operator and waives all such claims and remedies against
* the Registrar,
* the Registry Service Provider, and
* the Internet Corporation for Assigned Names and Numbers, as well as their directors, officers, employees, and agentsʺ
* ʺThe Challenger certifies that the information contained in this Challenge is to the best of Challengerʹs knowledge complete and accurate, that this Challenge is not being presented for any improper purpose, such as to harass, and that the assertions in this Challenge are warranted under these Rules and under applicable law, as it now exists or as it may be extended by a good-faith and reasonable argument.ʺ; and
- Annex any documentary or other evidence, together with a schedule indexing such evidence

The Challenge may relate to more than one domain name, provided that the domain names are registered by the same Challenger and were the subject of the same Decision which forms the basis of the Challenge filing

The Registry Operator shall review the Challenge for formal compliance with this MEFRP Policy, and will provide the Challenger with a period of time, not to exceed 5 calendar days, to correct any deficiencies or supply additional information. The Registry Operator shall then appoint a Community Panel to hear the Challenge.

The Registry Operator shall send to the Community Panel, upon its appointment, a copy of the Challenge, including any annexes, and a statement from the Registry Operator outlining the reasons for its Decision
- The Community Panel shall:
* conduct the proceeding in such manner as it considers appropriate in accordance with this Policy;
* ensure that the Parties are treated with equality and that each Party is given a fair opportunity to present its case;
* ensure that the proceeding takes place with due expedition. It may, at the request of a Party or on its own motion, extend, in exceptional cases, a period of time fixed by these Rules or by the Community Panel
* determine the admissibility, relevance, materiality and weight of the evidence;
* in its sole discretion, request any additional information from either the Challenger or the Registry Operator that it deems necessary in order to make its Finding
- There shall be no in-person hearings (including hearings by teleconference, videoconference, and web conference), unless the Community Panel determines, in its sole discretion and as an exceptional matter, that such a hearing is necessary for deciding the Challenge
- The Community Panel shall decide a Challenge on the basis of the statements and documents submitted and in accordance with this Policy, the “.MERCK” Registration Restrictions and Use Policy, and any rules and principles of law that it deems applicable. In the absence of exceptional circumstances, the Panel shall forward its Finding on the Challenge to the Parties no later than twenty (20) business days from its appointment. All Findings shall be made by majority

The remedies available to a Challenger pursuant to any proceeding before a Community Panel shall be limited to, as appropriate:
* the issuance by the Registry Operator of a Merck Community Membership ID,
* the issuance by the Registry Operator of an Approval Statement for a requested domain name registration, or
* the issuance by the Registry Operator of a new Approval Statement, enabling the Challenger to re-register a domain name previously revoked under the initial Decision.
- Should the Panel decide in favor of the Challenger the Registry Operator shall, no later than 14 days from the issuance of the Panel’s decision, provide the Challenger with the panel-ordered Merck Community Membership ID or Approval Statement, as appropriate

D.6 Maintaining the Status Quo

We will not request the Registrar to cancel, transfer, activate, deactivate, or otherwise change the status of any domain name registration the subject of a Challenge, or held by a Challenger bringing a Challenge regarding the revocation of either its Merck Community Membership ID or Approval Statement, during the pendency of any proceeding brought pursuant to this Policy.

D.7 Settlement or Other Grounds for Termination

If, before the Community Panel has reached its Finding, the Parties agree on a settlement, the Community Panel shall terminate the proceeding.

D.8 Transfers During a Dispute

- Transfers of a Domain Name to a New Holder. You may not transfer your domain name registration to another holder (i) during a pending proceeding brought pursuant to this Policy or for a period of fifteen (15) business days (as observed in the location of the Registrar’s principal place of business) after such proceeding is concluded; or (ii) during a pending court proceeding or arbitration commenced regarding your domain name, unless you have received permission for said transfer (pursuant to the “.MERCK” Registration Restrictions and Use Policy) from the Registry Operator, and the party to whom the domain name registration is being transferred agrees, in writing, to be bound by the decision of the court or arbitrator. We reserve the right to request the Registrar to cancel any transfer of a domain name registration to another holder that is made in violation of this subparagraph, or in violation of the terms and conditions of the “.MERCK” Registration Restrictions and Use Policy.
- Changing Registrars. You may not transfer your domain name registration to another registrar during a pending proceeding brought pursuant to this Policy or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded. You may transfer administration of your domain name registration to another registrar during a pending court action or arbitration, provided that the domain name you have registered shall continue to be subject to the proceeding commenced by you in accordance with the terms of this Policy.

D.9 Policy Modifications

We reserve the right to modify this Policy at any time with the permission of ICANN. We will post our revised Policy at [insert URL when finalized] at least thirty (30) calendar days before it becomes effective. Unless this Policy has already been invoked by the submission of a Challenge, in which event the version of the Policy in effect at the time it was invoked will apply to you until the dispute is over, all such changes will be binding upon you with respect to any domain name registration dispute, whether the dispute arose before, on or after the effective date of our change. In the event that you object to a change in this Policy, your sole remedy is to cancel your “.MERCK” domain name registration, provided that you will not be entitled to a refund of any fees paid. The revised Policy will apply to you until you cancel or fail to renew your “.MERCK” domain name registration.


F. Rights protection resourcing plans

Merck KGaA will provide members of its legal department staff to review membership applications, review requests for domain name strings, and process business related to the Charter Eligibility Dispute Resolution Policy (CEDRP) and the “.MERCK” Eligibility and Functionality Reconsideration Policy (MEFRP). During the start-up⁄roll-out period, this function may require the full-time equivalent of one staff member. The responsibilities may be split among several existing staff members, including a staff attorney or attorneys, and an administrator⁄manager. On an ongoing basis, these RPM functions will require the full-time equivalent of one-half staff member.

Supporting RPMs also requires several departments within the registry operator as well as within Afilias. The implementation of Sunrise and the Trademark Claims service and on-going RPM activities will pull from the 102 Afilias staff members of the engineering, product management, development, security and policy teams at Afilias and staff at the Registry Operator. No additional hardware or software resources are required to support this as Afilias has fully-operational capabilities to manage abuse today.

30(a). Security Policy: Summary of the security policy for the proposed registry

The answer to question #30a is provided by Afilias, the back-end provider of registry services for this TLD.

Afilias aggressively and actively protects the registry system from known threats and vulnerabilities, and has deployed an extensive set of security protocols, policies and procedures to thwart compromise. Afilias’ robust and detailed plans are continually updated and tested to ensure new threats are mitigated prior to becoming issues. Afilias will continue these rigorous security measures, which include:

- Multiple layers of security and access controls throughout registry and support systems;
- 24x7 monitoring of all registry and DNS systems, support systems and facilities;
- Unique, proven registry design that ensures data integrity by granting only authorized access to the registry system, all while meeting performance requirements;
- Detailed incident and problem management processes for rapid review, communications, and problem resolution, and;
- Yearly external audits by independent, industry-leading firms, as well as twice-yearly internal audits


A. Security policies and protocols

Afilias has included security in every element of its service, including facilities, hardware, equipment, connectivity⁄Internet services, systems, computer systems, organizational security, outage prevention, monitoring, disaster mitigation, and escrow⁄insurance, from the original design, through development, and finally as part of production deployment. Examples of threats and the confidential and proprietary mitigation procedures are detailed in our response to question #30(b).

There are several important aspects of the security policies and procedures to note:

- Afilias hosts domains in data centers around the world that meet or exceed global best practices
- Afilias’ DNS infrastructure is massively provisioned as part of its DDoS mitigation strategy, thus ensuring sufficient capacity and redundancy to support new gTLDs
- Diversity is an integral part of all of our software and hardware stability and robustness plan, thus avoiding any single points of failure in our infrastructure
- Access to any element of our service (applications, infrastructure and data) is only provided on an as-needed basis to employees and a limited set of others to fulfill their job functions. The principle of least privilege is applied
- All registry components – critical and non-critical – are monitored 24x7 by staff at our NOCs, and the technical staff has detailed plans and procedures that have stood the test of time for addressing even the smallest anomaly. Well-documented incident management procedures are in place to quickly involve the on-call technical and management staff members to address any issues

Afilias follows the guidelines from the ISO 27001 Information Security Standard (Reference: http:⁄⁄www.iso.org⁄iso⁄iso_catalogue⁄catalogue_tc⁄catalogue_detail.htm?csnumber=42103 ) for the management and implementation of its Information Security Management System. Afilias also utilizes the COBIT IT governance framework to facilitate policy development and enable controls for appropriate management of risk (Reference: http:⁄⁄www.isaca.org⁄cobit). Best practices defined in ISO 27002 are followed for defining the security controls within the organization. Afilias continually looks to improve the efficiency and effectiveness of our processes, and follows industry best practices as defined by the IT Infrastructure Library, or ITIL (Reference: http:⁄⁄www.itil-officialsite.com⁄).

The Afilias registry system is located within secure data centers that implement a multitude of security measures both to minimize any potential points of vulnerability and to limit any damage should there be a breach. The characteristics of these data centers are described fully in our response to question #30(b).

The Afilias registry system employs a number of multi-layered measures to prevent unauthorized access to its network and internal systems. Before reaching the registry network, all traffic is required to pass through a firewall system. Packets passing to and from the Internet are inspected, and unauthorized or unexpected attempts to connect to the registry servers are both logged and denied. Management processes are in place to ensure each request is tracked and documented, and regular firewall audits are performed to ensure proper operation. 24x7 monitoring is in place and, if potential malicious activity is detected, appropriate personnel are notified immediately.

Afilias employs a set of security procedures to ensure maximum security on each of its servers, including disabling all unnecessary services and processes and regular application of security-related patches to the operating system and critical system applications. Regular external vulnerability scans are performed to verify that only services intended to be available are accessible.

Regular detailed audits of the server configuration are performed to verify that the configurations comply with current best security practices. Passwords and other access means are changed on a regular schedule and are revoked whenever a staff member’s employment is terminated.

A.1 Access to registry system

Access to all production systems and software is strictly limited to authorized operations staff members. Access to technical support and network operations teams where necessary are read only and limited only to components required to help troubleshoot customer issues and perform routine checks. Strict change control procedures are in place and are followed each time a change is required to the production hardware⁄application. User rights are kept to a minimum at all times. In the event of a staff member’s employment termination, all access is removed immediately.

Afilias applications use encrypted network communications. Access to the registry server is controlled. Afilias allows access to an authorized registrar only if each of the authentication factors matches the specific requirements of the requested authorization. These mechanisms are also used to secure any web-based tools that allow authorized registrars to access the registry. Additionally, all write transactions in the registry (whether conducted by authorized registrars or the registryʹs own personnel) are logged.

EPP connections are encrypted using TLS⁄SSL, and mutually authenticated using both certificate checks and login⁄password combinations. Web connections are encrypted using TLS⁄SSL for an encrypted tunnel to the browser, and authenticated to the EPP server using login⁄password combinations.

All systems are monitored for security breaches from within the data center and without, using both system-based and network-based testing tools. Operations staff also monitor systems for security-related performance anomalies. Triple-redundant continual monitoring ensures multiple detection paths for any potential incident or problem. Details are provided in our response to questions #30(b) and #42. Network Operations and Security Operations teams perform regular audits in search of any potential vulnerability.

To ensure that registrar hosts configured erroneously or maliciously cannot deny service to other registrars, Afilias uses traffic shaping technologies to prevent attacks from any single registrar account, IP address, or subnet. This additional layer of security reduces the likelihood of performance degradation for all registrars, even in the case of a security compromise at a subset of registrars.

There is a clear accountability policy that defines what behaviors are acceptable and unacceptable on the part of non-staff users, staff users, and management. Periodic audits of policies and procedures are performed to ensure that any weaknesses are discovered and addressed. Aggressive escalation procedures and well-defined Incident Response management procedures ensure that decision makers are involved at early stages of any event.

In short, security is a consideration in every aspect of business at Afilias, and this is evidenced in a track record of a decade of secure, stable and reliable service.


B. Independent assessment

Supporting operational excellence as an example of security practices, Afilias performs a number of internal and external security audits each year of the existing policies, procedures and practices for:

- Access control;
- Security policies;
- Production change control;
- Backups and restores;
- Batch monitoring;
- Intrusion detection, and
- Physical security

Afilias has an annual Type 2 SSAE 16 audit performed by PricewaterhouseCoopers (PwC). Further, PwC performs testing of the general information technology controls in support of the financial statement audit. A Type 2 report opinion under SSAE 16 covers whether the controls were properly designed, were in place, and operating effectively during the audit period (calendar year). This SSAE 16 audit includes testing of internal controls relevant to Afiliasʹ domain registry system and processes. The report includes testing of key controls related to the following control objectives:

- Controls provide reasonable assurance that registrar account balances and changes to the registrar account balances are authorized, complete, accurate and timely
- Controls provide reasonable assurance that billable transactions are recorded in the Shared Registry System (SRS) in a complete, accurate and timely manner
- Controls provide reasonable assurance that revenue is systemically calculated by the Deferred Revenue System (DRS) in a complete, accurate and timely manner
- Controls provide reasonable assurance that the summary and detail reports, invoices, statements, registrar and registry billing data files, and ICANN transactional reports provided to registry operator(s) are complete, accurate and timely
- Controls provide reasonable assurance that new applications and changes to existing applications are authorized, tested, approved, properly implemented and documented
- Controls provide reasonable assurance that changes to existing system software and implementation of new system software are authorized, tested, approved, properly implemented and documented.
- Controls provide reasonable assurance that physical access to data centers is restricted to properly authorized individuals
- Controls provide reasonable assurance that logical access to system resources is restricted to properly authorized individuals
- Controls provide reasonable assurance that processing and backups are appropriately authorized and scheduled and that deviations from scheduled processing and backups are identified and resolved

The last Type 2 report issued was for the year 2010, and it was unqualified, i.e., all systems were evaluated with no material problems found.

During each year, Afilias monitors the key controls related to the SSAE controls. Changes or additions to the control objectives or activities can result due to deployment of new services, software enhancements, infrastructure changes or process enhancements. These are noted and after internal review and approval, adjustments are made for the next review.

In addition to the PricewaterhouseCoopers engagement, Afilias performs internal security audits twice a year. These assessments are constantly being expanded based on risk assessments and changes in business or technology.

Additionally, Afilias engages an independent third-party security organization, PivotPoint Security, to perform external vulnerability assessments and penetration tests on the sites hosting and managing the Registry infrastructure. These assessments are performed with major infrastructure changes, release of new services or major software enhancements. These independent assessments are performed at least annually. A report from a recent assessment is attached with our response to question #30(b).

Afilias has engaged with security companies specializing in application and web security testing to ensure the security of web-based applications offered by Afilias, such as the Web Admin Tool (WAT) for registrars and registry operators.

Finally, Afilias has engaged IBM’s Security services division to perform ISO 27002 gap assessment studies so as to review alignment of Afilias’ procedures and policies with the ISO 27002 standard. Afilias has since made adjustments to its security procedures and policies based on the recommendations by IBM.


C. Special TLD considerations

Afilias’ rigorous security practices are regularly reviewed; if there is a need to alter or augment procedures for this TLD, they will be done so in a planned and deliberate manner.


D. Commitments to registrant protection

With over a decade of experience protecting domain registration data, Afilias understands registrant security concerns. Afilias supports a “thick” registry system in which data for all objects are stored in the registry database that is the centralized authoritative source of information. As an active member of IETF (Internet Engineering Task Force), ICANN’s SSAC (Security & Stability Advisory Committee), APWG (Anti-Phishing Working Group), MAAWG (Messaging Anti-Abuse Working Group), USENIX, and ISACA (Information Systems Audits and Controls Association), the Afilias team is highly attuned to the potential threats and leading tools and procedures for mitigating threats. As such, registrants should be confident that:

- Any confidential information stored within the registry will remain confidential;
- The interaction between their registrar and Afilias is secure;
- The Afilias DNS system will be reliable and accessible from any location;
- The registry system will abide by all polices, including those that address registrant data;
- Afilias will not introduce any features or implement technologies that compromise access to the registry system or that compromise registrant security

Afilias has directly contributed to the development of the documents listed below and we have implemented them where appropriate. All of these have helped improve registrants’ ability to protect their domains name(s) during the domain name lifecycle.

- [SAC049]: SSAC Report on DNS Zone Risk Assessment and Management (03 June 2011)
- [SAC044]: A Registrantʹs Guide to Protecting Domain Name Registration Accounts (05 November 2010)
- [SAC040]: Measures to Protect Domain Registration Services Against Exploitation or Misuse (19 August 2009)
- [SAC028]: SSAC Advisory on Registrar Impersonation Phishing Attacks (26 May 2008)
- [SAC024]: Report on Domain Name Front Running (February 2008)
- [SAC022]: Domain Name Front Running (SAC022, SAC024) (20 October 2007)
- [SAC011]: Problems caused by the non-renewal of a domain name associated with a DNS Name Server (7 July 2006)
- [SAC010]: Renewal Considerations for Domain Name Registrants (29 June 2006)
- [SAC007]: Domain Name Hijacking Report (SAC007) (12 July 2005)

To protect any unauthorized modification of registrant data, Afilias mandates TLS⁄SSL transport (per RFC 5246) and authentication methodologies for access to the registry applications. Authorized registrars are required to supply a list of specific individuals (five to ten people) who are authorized to contact the registry. Each such individual is assigned a pass phrase. Any support requests made by an authorized registrar to registry customer service are authenticated by registry customer service. All failed authentications are logged and reviewed regularly for potential malicious activity. This prevents unauthorized changes or access to registrant data by individuals posing to be registrars or their authorized contacts.

These items reflect an understanding of the importance of balancing data privacy and access for registrants, both individually and as a collective, worldwide user base.

The Afilias 24⁄7 Customer Service Center consists of highly trained staff who collectively are proficient in 15 languages, and who are capable of responding to queries from registrants whose domain name security has been compromised – for example, a victim of domain name hijacking. Afilias provides specialized registrant assistance guides, including specific hand-holding and follow-through in these kinds of commonly occurring circumstances, which can be highly distressing to registrants


E. Security resourcing plans

Please refer to our response to question #30b for security resourcing plans.



© Internet Corporation For Assigned Names and Numbers.