Recommendations for Managing the IDN variant TLDs

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 with other domain labels and therefore the "same" labels, referred to as variant labels. The IDNs in Applications (IDNA) 2008 standard, while stipulating how to use domain names in multiple scripts, also asks in RFC 58941 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. … In general, users will benefit if registries only permit characters from scripts that are well-understood by the registry or its advisers."

Based on the IDNA2008 standard, variant labels must minimally be identified and managed to ensure that end-users are prevented from any security threats. A few of the variant labels identified could even be activated to promote usability of the IDNs, as different language communities using a script may use a different variant label. In some cases, applications for IDN ccTLDs and new gTLDs have identified additional labels considered as variant labels, indicating that the community may consider these different labels as variants of each other. However, due to lack of a clear definition and a solution to implement them, 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 directed 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 as part of the new gTLD process in order to facilitate the development of workable approaches to the deployment of gTLDs containing variant characters IDNs."

Achieving these security and usability goals in a stable manner is the key challenge to be addressed. To address these complex linguistic and technical issues, ICANN organization undertook the IDN Variant Issues Project under the guidance of the ICANN Board. As a first step, it engaged with experts from six script communities, who analyzed issues in identifying variant labels for each of these scripts. This analysis of issues for Arabic, Chinese, Cyrillic, Devanagari, Greek, and Latin scripts in 2011, integrated in the Integrated Issues Report (IIR) (2012) identified two challenges:

"in the DNS environment today, there is no accepted definition for what may constitute a variant relationship between top-level labels
"nor is there a 'variant management' mechanism for the top level, although such has often been proposed as a way to facilitate solutions to a particular problem."
1. Defining Variant TLDs

IIR outlined the follow-on work that might be undertaken. To address the first problem noted in IIR, the community developed Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels (RZ-LGR Procedure). Based on the direction of the ICANN Board on 11 April 2013, ICANN undertook RZ-LGR Procedure which follows a two-step process, requiring each community to develop individual script-based Label Generation Rules (LGR) proposal and an expert panel to review and integrate each proposal into the Root Zone LGR (RZ-LGR). Multiple 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 in defining their rules. Further, a specification to encode these linguistic details into a formal machine-readable format has also been developed and released through 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.

2. Analyzing Variant TLD Management Mechanisms

The label generation rules for the root zone derived from the process described above produce variant TLD labels that are candidates for allocation. To address the second part of the need stated in Integrated Issues Report for a variant management mechanism for the top level, it is necessary for the ICANN community to develop the policies and procedures that govern such allocation of variant names. The set of documents, finalized after public comment and published, offer recommendations for consideration by the ccNSO and GNSO during the development of relevant policies and procedures in accordance with their respective Policy Development Processes (PDPs). These documents also analyze the recommendations and their impact on the gTLD application process, as described in the New gTLD Applicant Guidebook, and on the IDN ccTLD application process, based on the Final Implementation Plan for the IDN ccTLD Fast Track Process. The fundamental premises for the recommendations and analysis presented arise mostly from observations by the community in Integrated Issues Report and advice presented by the Security and Stability Advisory Committee (SSAC) in its SAC 60 report.

While developing the analysis, ICANN organization team has had multiple interactions with the ICANN Board IDN Working Group (BIWG) since 2014, and the BIWG has guided the development of this work. The recommendations have been designed to be conservative, with the view that the IDN variant TLDs are being implemented for the first time, and that the solution could accommodate implementation experience over time.

The ICANN Board notes that the RZ-LGR work is well underway. The ICANN Board also notes that the initial set of recommendations for implementing IDN variant TLDs in a conservative and consistent way are available for further consideration by the ccNSO and GNSO in their work on developing relevant policy and procedures. With the prerequisites identified by the community in Integrated Issues Report in place, the next steps can now be taken by the supporting organizations (SOs).

This will have a positive impact for the community, though there are some associated risks. Minimally, the IDN variant TLDs identified are withheld from application, which will contribute towards the security of the end users, until possibly a feasible management mechanism has been developed by the supporting organizations. Further, if consistent management mechanisms can be agreed by the ccNSO and GNSO on delegating a few of these variant labels, it can help promote the usability of the domain names across the communities which require these IDN variant TLDs. There is risk associated with taking this work forward, especially if a consistent approach to TLDs is not agreed upon by the community, as that can potentially confuse the end-users, or in other cases may cause security issues for them. The IDN variant TLDs can also cause management burden on registrants, as identified by SSAC in its SAC060 report. Following the resolution, ccNSO and GNSO will have to develop their own policies and procedures to implement IDN variant TLDs, taking into account recommendations provided. This resolution, however, is not directing either the ccNSO or the GNSO to undertake policy work on this topic. If and when the respective Final Reports containing policy recommendations, developed through the appropriate PDPs, are submitted to the ICANN Board for approval, the Board will consider how effectively these policies and procedures address the Variant TLD recommendations, their impact and the associated risks. At that time the Board will decide whether to adopt the policy recommendations and move forward with implementing the IDN variant TLDs.

There will eventually be a fiscal impact. The extent of the fiscal impact will depend on the eventual IDN variant TLD application evaluation process and the timing of this application process suggested by the community. Therefore, the impact will need to be gauged when the ccNSO and GNSO finalize their policies and procedures for implementing IDN variant TLDs and present them for consideration by the ICANN Board.

The recommendations contribute towards a secure and stable operation of the unique identifier system, while addressing the need for IDN variant TLDs identified by the community and respecting the community policy development role. The work on IDN variant TLDs also contributes to the public interest by enhancing access to the Internet's Domain Name System (DNS) in different scripts and languages.