Skip to main content

Summary and Analysis of Specification 13 Public Comments

As a result of sincere and constructive discussions and negotiations, a proposed Specification 13 is in our hands. If approved by NGPC, Specification 13 would provide limited accommodations to registry operators of TLDs that qualify as “.Brand TLDs.” As many as one-third of all new gTLD applications might qualify as .Brand TLDs.

On 6 December 2013, we posted a draft of the proposed Specification 13 for public comment. In response to the proposed draft the ICANN community submitted dozens of thoughtful and constructive comments, leading to several modifications and, what I hope to be, the final draft. The summary and analysis of public comments can be viewed here [PDF, 550 KB].

The accommodations proposed in the revised version of Specification 13 Base Agreement [PDF, 244 KB] and Change-Pro Redline [PDF, 265 KB] are as follows:

  • Exemption from the Specification 9 of the Registry Agreement. Specification 9, also referred to as the Code of Conduct, is designed to protect the TLD’s registrants, but in the case of a .Brand there is no need to protect the .Brand operator from itself.
  • Deferral of Sunrise requirements. A .Brand TLD’s requirement to conduct a Sunrise registration period would be deferred for as long as the TLD continues to qualify as a .Brand TLD. If the TLD ever ceases to operate as a .Brand TLD, then the TLD would have to comply with the Sunrise requirements and hold a Sunrise period within 60 days.
  • A 2-year “cooling-off” period prior to re-delegation of the .Brand TLD to a successor registry operator, in most cases. The provision does not prevent ICANN’s appointment of an EBERO.
  • Registry Operator must conduct an annual self-audit and certify that the TLD continues to qualify as a .Brand TLD.
  • Revised definitions of “.Brand TLD” and “Trademark Licensee” to address concerns and adopt several suggestions of the commentators.
  • Removal of the ability of the .Brand registry operator to designate exclusive registrars for the TLD.

Now the ICANN community is able to review this final draft before it is submitted to the New gTLD Program Committee for consideration at ICANN 49 in Singapore.

I would like to thank the Brand Registry Group for their consistently professional and constructive negotiations in defining and drafting the proposed specification.

Please email me with any comments or feedback on the proposed final draft of Specification 13 at


    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."