Skip to main content

500+ New gTLD Agreements Signed & Counting

During a recent webinar, a question was posed about what types of negotiated changes to the standard New gTLD Registry Agreement template have been agreed upon thus far between ICANN and registry applicants.

As of 12 September 2014, ICANN has executed 515 New gTLD Registry Agreements. During the past year, dozens of applicants have requested changes to the standard Registry Agreement contract template, and ICANN has engaged in considerable discussions and negotiations in an effort to understand the legal and/or commercial justification, motivation and reasoning behind these requests.

The New gTLD Registry Agreement was adopted only after extensive consultation and negotiation with the whole of the ICANN community. It was developed through the ICANN multi-stakeholder model, with extensive community feedback and public comments from a variety of stakeholders, including negotiations between ICANN and a Registry Agreement Negotiation Team comprised of volunteers from the Registries Stakeholder Group, the New TLD Applicant Group, the Brand Registry Group and individual applicants. The process included the posting of multiple drafts that were subject to public comment periods, providing the ICANN community with multiple opportunities for feedback and comments.

Accordingly, ICANN believes that substantive changes to the standard Registry Agreement contract template should only be made if an applicant makes a compelling and persuasive case justifying why it should be treated differently than other applicants. Permitting changes to the Registry Agreement for any individual applicant absent the existence of such factors would be generally inconsistent with key principles of fairness and equal treatment that are fundamental to ICANN's consensus-driven, multi-stakeholder model.

The Applicant Guidebook itself states (emphasis added):

All successful applicants are expected to enter into the agreement substantially as written. Applicants may request and negotiate terms by exception; however, this extends the time involved in executing the agreement. In the event that material changes to the agreement are requested, these must first be approved by the ICANN Board of Directors before execution of the agreement.

In light of these considerations, to date, not one of the 515 executed New gTLD Registry Agreements includes any negotiated changes to the standard contract language template.

To be clear, without changing the standard contract language template, ICANN has engaged in negotiations with various applicants over a number of matters relating to the Registry Agreement, such as the scope of approved Registry Services set forth in Exhibit A, whether the applicant qualifies for Specification 13 or the Code of Conduct exemption, whether the applicant qualifies for use of alternate standard provisions in the contract language template applicable to governmental entities or intergovernmental organizations, and the terms of Specification 11 (Public Interest Commitments) and Specification 12 (Community Registration Policies).

Consistent with ICANN's commitments to openness and transparency, we post redlined versions of each Registry Agreement after it is executed showing any changes that have been made. See

We look forward to continuing to engage with the applicant community and to signing additional New gTLD Registry Agreements.


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."