Skip to main content

Two-Character Letter/Letter Comments Consideration Process


As of 13 December 2016, this process has been retired and this page will no longer be updated. For more information regarding the retired process, please click here. For current information regarding Two-Character ASCII Labels, please go here:

The Two-Character Letter/Letter Comments Consideration Process was launched on 6 October 2015 and is the process by which labels that have received comments regarding their release will be evaluated. A workflow and additional information about the process can be found below. The Comments Consideration Process is a subprocess of the Authorization Process for Release of Two-Character ASCII Labels, under which a registry operator may submit a request for ICANN's authorization to release one or more two-character letter/letter ASCII labels.

More information regarding the Authorization Process for Release of Two-Character ASCII Labels can be found on the Authorization Process webpage.

Submitting and Viewing Comments and Mitigation Measures

Comments Consideration Process

Flowchat for the Two-Character Comments Consideration Process
  1. ICANN reaches out to all relevant governments to further clarify their comments.

    ICANN will reach out to all governments that have submitted comments to better understand their concerns, including why a relevant government may believe a specific label.TLD combination causes confusion with the corresponding country code. As ICANN evaluates the responses to our outreach, comments not pertaining to confusion might be directed to recourse mechanisms outside of the Authorization Process, such as the Abuse Point of Contact, which is used when abuse is suspected.

  2. ICANN reaches out to registries to respond with a mitigation plan.

    ICANN will ask registries to respond to relevant governments' comments with measures to be implemented to avoid confusion with corresponding country codes. As with the governments' comments clarification, the registries' mitigation plans will be published.

  3. ICANN aggregates governments' comments and registries' mitigation plans to draft the criteria for approval.

    Once ICANN has received feedback within the allotted timeframe from both governments and registries, ICANN will aggregate the comments that governments have raised, as well as the mitigation measures that registries have identified. From those inputs, ICANN will endeavor to find commonality to draft the criteria by which ICANN can evaluate whether the measures identified by a registry successfully mitigate the confusion raised by the government. These draft criteria will be posted for public comment before final adoption.

  4. ICANN takes into consideration the feedback provided by community and creates finalized criteria for approval.

    Taking into consideration the feedback provided by the community during the Public Comment period, ICANN will strive to produce a finalized set of criteria for approval, which will be used to evaluate mitigation plans provided by the registries for previously commented on labels. Moreover, these finalized criteria for approval may be used to evaluate all future two-character authorization requests that receive comments from relevant governments. Considering the breadth of TLDs involved, it is conceivable that multiple sets of criteria could be adopted to apply to different subsets of TLDs such as those with a Specification 13 provision for a brand TLD.

    The current framework of the Authorization Process, whereby a registry submits an authorization request and relevant governments may submit comments, is not expected to change. However, we believe the finalized criteria for approval will help everyone with a more clearly defined standard with which ICANN can evaluate future requests.

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