ICANN: Recommendations for Managing IDN Variant Top-Level Domains

Purpose:

Recommendations for managing Internationalized Domain Name (IDN) variant labels for top level domains (TLDs) have been developed by ICANN organization. The relevant materials along with the recommendations are being published to seek community feedback for finalizing them.

Current Status:

The community has identified a need for IDN variant TLDs; however, the ICANN Board resolved on 25 September 2010 that “no variants of gTLDs will be delegated … until appropriate variant management solutions are developed.” Subsequent work by ICANN organization and the community led to the identification of two issues: (i) there is no accepted definition for variant TLDs, and (ii) there is no ‘variant management’ mechanism for TLDs. For the first issue, the Root Zone Label Generation Rules (RZ-LGR) Procedure was developed with the support of the community and adopted by the ICANN Board on 11 April 2013 for implementation. The Procedure has been implemented and RZ-LGR has been developed for six scripts, and other scripts are being added as their proposals are finalized by the relevant script communities. For the second issue, ICANN organization has undertaken a detailed examination to develop a set of recommendations on variant management mechanisms for TLDs, which will be finalized based on the community input.

Next Steps:

The finalized recommendations will be presented to the ICANN Board, anticipated in March 2019. At that time, the ICANN Board will be requested to consider these recommendations to allow for implementing IDN variant TLDs.

The Board resolved in 2010 for ICANN organization to look into the management mechanisms for IDN Variant TLDs, to address relevant and complex linguistic, technical and policy issues. The subsequent work undertaken by ICANN organization and the community identified two challenges: (i) there is no accepted definition for variant TLDs, and (ii) there is no ‘variant management’ mechanism for TLDs.

To resolve the first issue, the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels (RZ-LGR Procedure) was developed in collaboration with the community. Based on the direction of the ICANN Board in 2013, ICANN undertook this procedure to develop RZ-LGR. Eight script communities have finalized their proposals, from which Arabic, Ethiopic, Georgian, Khmer, Lao and Thai script proposals have been integrated into its second version, RZ-LGR-2. Many other script communities are also active and developing proposed rules. Further, a specification to encode these linguistic details into a formal machine-readable format has also been developed and released by IETF as standards track RFC 7940: Representing Label Generation Rulesets Using XML. A LGR tool has also been developed to create, use and manage the LGRs, and is available for the community online as well as for download with an open source license. The process, and the label generation rules for the root zone that result, produce variant TLD labels that are candidates for allocation and possible delegation.

To address the second issue, regarding a variant management mechanism for TLDs, it is necessary for the ICANN community to develop the policies and procedures that govern withholding, allocating and possibly delegating such variant TLD labels. This public comment period presents the following materials for review and feedback of the community, cumulatively as a proposal for the management mechanism for the IDN Variant TLDs.

1. IDN Variant TLD Implementation – Executive Summary
2. IDN Variant TLD Implementation – Motivation, Premises and Framework
3. IDN Variant TLD Implementation – Recommendations and Analysis
4. IDN Variant TLD Implementation – Rationale for RZ-LGR
5. IDN Variant TLD Implementation – Risks and their Mitigation
6. IDN Variant TLD Implementation – Appendices (A: Definitions, B: Use of ROID, C: Limiting Allocated Variant TLDs)

These documents will be finalized based on feedback from the community, to be presented to the ICANN Board for consideration in response to its 2010 resolution.

Specific feedback is sought on the following questions:

1. The rationale for the RZ-LGR requires strictly adhering to the IDN variant label sets defined by the community through the RZ-LGR. Is this a reasonable pre-requisite for implementing IDN Variant TLDs?
2. Do the proposed recommendations appropriately address the management and implementation of the IDN Variant TLDs?
   1. Do any suggested recommendations need to be changed? Why?
   2. Are any additional recommendations needed?
3. Does the analysis suitably cover the impact of the recommendations on existing procedures for IDN ccTLDs and IDN gTLDs? Is there alternate analysis for certain cases? Are there any additional impacts on the procedures not identified?
4. Which (if any) of the recommendations require policy consideration by GNSO and ccNSO, whereas the remaining would only have an impact on procedures?
5. To prevent the permutation issue which can be introduced by using variant labels, as identified by SSAC, how may the allocated IDN Variant TLD labels be limited? Are the mechanisms suggested in Appendix C appropriate? What other factors may also be relevant?
6. Are the risks and their mitigation measures sufficiently comprehensive? Are there any additional risks? Should there be different or additional mitigation measures?

Internationalized Domain Names (IDNs) enable people around the world to use domain names in local languages and scripts. Some script communities have identified that technically distinct domain labels may be considered indistinguishable or interchangeable with other domain labels, referred to as IDN variant labels. The IDNs in Applications (IDNA) 2008 standard, while stipulating how to use domain names in multiple scripts, also reflects on extra measures which are needed to manage confusability. RFC 5890, suggests that “DNS zone administrators may impose restrictions, beyond those imposed by DNS or IDNA, on the characters or strings that may be registered as labels in their zones. Because of the diversity of characters that can be used in a U-label [using Unicode standard] and the confusion they might cause, such restrictions are mandatory for IDN registries and zones even though the particular restrictions are not part of these specifications.” It is further explained that “DNS zone administrators may impose restrictions … that try to minimize characters that have similar appearance or similar interpretations.” It is re-iterated in RFC 5891 that “Registries at all levels of the DNS, … [including] the top level, are expected to establish policies about label registrations,” specifically pointing to the rationale in RFC 5894 that “registries should develop and apply additional restrictions as needed to reduce confusion and other problems … For many scripts, the use of variant techniques … may be helpful in reducing problems that might be perceived by users.”

Some IDN ccTLD and new gTLD applicants have indicated that the community may consider different labels as variants of each other. However, due to lack of a clear definition or a solution to implement them, the ICANN Board resolved on 25 September 2010 that “no variants of gTLDs will be delegated through the New gTLD Program until appropriate variant management solutions are developed.” The resolution further directs ICANN staff to develop “an issues report identifying what needs to be done with the evaluation, possible delegation, allocation and operation of gTLDs containing variant characters IDNs … in order to facilitate the development of workable approaches to the deployment of gTLDs containing variant characters IDNs.”

Based on IDNA2008, variant labels should be identified and managed to help minimize the end-user confusability introduced by IDNs. Some of these variant labels could even be activated to promote accessibility of the IDNs, as different language communities using a script may use different variant labels. Achieving these security and usability goals in a stable manner is the key challenge to be addressed.

Background materials: