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: https://www.icann.org/resources/two-character-labels
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
- Submit a comment regarding a specific letter/letter label request using the Two-Character Comment web form.
- Submit mitigation measures for two-character label requests that have received comments using the Registry Operator's Mitigation Measures to Avoid Confusion web form.
View existing Two-Character Letter/Letter Comments and Mitigation Measures
- Comments submitted before 6 October 2015 are displayed separately on the Two-Character Comments Archive page
Comments Consideration Process
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.
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.
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.
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.