EPDP on Internationalized Domain Names

EPDP on Internationalized Domain Names
Status:	Active
Issue Areas:	Internationalized Domain Names
Date Established:	2021/05/20
Charter:	WG Charter
Workspace:	Community Wiki

The EPDP on Internationalized Domain Names (IDNs) is to provide the GNSO Council with policy recommendations on the definition of all gTLDs and the management of variant labels to facilitate the delegation variant gTLDs in the root zone while maintaining the the security, stability, and resiliency of the DNS; and how to update the IDN Implementation Guidelines, with which Contracted Parties must comply.

History

In October 2020, an IDN scoping team released its Final Report, which recommended an EPDP, which the GNSO Council initiated in November 2020. The charter drafting team built on the existing body of work on IDNs, such as recommendations from the gTLD Subsequent Procedures PDP, IDN variant TLD implementation, and the Root Zone Label Generation Rules (RZ-LGR). On May 10, 2021, the drafting team submitted its deliverables, such as the definition of all gTLDs and the management of variant labels and how IDN Implementation Guidelines should be updated. Ten days later, the GNSO Council approved the initiation request for the EPDP-IDNs and adopted its charter. The EPDP-IDNs working group held its first meeting on 11 August 2021. In August 2022, the working group completed its first substantive deliberations on questions related to four topics.

Drafting First Group Recommendations

As of December 2022, the EPDP Team had developed draft the following draft recommendations.

1. The definition of all gTLDs using the RZ-LGR:

   The EPDP Team recommends that

   • the RZ-LGR be the sole source to calculate the variant labels and disposition values for existing delegated gTLD labels.
   • SubPro’s limited challenge mechanism for DNS Stability Review applies in cases where the applicant believes that the label is valid as per the RZ-LGR and that the DNS Stability Panel has incorrectly assessed the label as "invalid", thus resulting in the application having been incorrectly disqualified.
   • No ceiling value is necessary as existing measures in the RZ-LGR to reduce the number of allocatable top-level variant labels, as well as economic, operational, and other factors that may impact the decision to seek to activate variant labels will keep the number of activated top-level variant labels conservative.
   • Best practice guidelines should be developed for the management of a gTLD and its variant labels by registries and registrars with a view to ensuring a consistent user experience.
   • Any existing gTLDs and their delegated and allocated variant labels (if any) not validated by a proposed RZ-LGR update must be grandfathered. In other words, the proposed update will apply to future new gTLDs and their variant labels and will not be retrospective; there will be no change to the contractual and delegation status of existing gTLDs and their delegated and allocated variant labels (if any), which predate the proposed RZ-LGR update and are subject to the version of RZ-LGR when those labels were delegated or allocated.
   • For all future versions of the RZ-LGR, Generation Panels (GPs) and the Integration Panel (IP) must make best efforts to retain full backward compatibility with existing gTLDs and their delegated and allocated variant labels (if any). The LGR Procedure must be updated to specify the exceptional circumstances, to the extent known to the GPs and IP, that could result in a proposed update to the RZ-LGR not being able to retain full backward compatibility.
   • In the unexpected event where a proposed update of the RZ-LGR is unable to retain full backward compatibility for validating any existing gTLDs as well as their delegated and allocated variant labels (if any), the relevant GP must call out the exception during a public comment period and explain the reasons for such exception.
   • Single-character gTLDs may only be allowed for limited scripts and languages where a character is an ideograph. At the time of the EPDP Team's deliberation, the script that meets the criteria is the Han script, which is used in the Chinese, Japanese, and Korean languages. Applications for single-character gTLDs will not be accepted until relevant guidelines from the Chinese, Japanese, and Korean language communities are implemented in the New gTLD Program.

1. the “same entity” principle at the top level,
2. variants’ impact on the New gTLD Program, and
3. string similarity review.

The second group of issues includes:

1. Same Entity at Second-Level,
2. Domain Name Lifecycle,
3. Rights Protection Mechanisms, and
4. IDN Implementation Guidelines.

In ICANN 75 Session 1, the WG presented its plan to break the initial report into "chunks." It has several reasons for doing so including:

1. its charter deliberation is behind schedule due to the breadth and complexity of issues related to IDN variants,
2. more data need to be collected from registries, registrars, and RSPs about second-level variant management,
3. the impact on the New gTLD Application process and SubPro recommendation implementation, and
4. “Second-level” charter questions following gTLD delegation that new gTLD applicants do not need to address.

In ICANN 75 Session 2, the WG presented its findings from a survey among Chinese and Arabic ROs, of which 20/26 and 2/9 responded, respectively. In terms of interest in Activating Variants, 12 Chinese ROs and 2 Arabic ROs responded, "Yes.” Potential factors affecting their future decisions included market condition, business potential, registrar interest, variant domain use and access, the New Applicant Guidebook, IDN policies, contractual terms, cost/fees, the application, transactions, management/hosting, variant domain management, complexity, behavior, resolution system design, capacity expansion, specific gTLD launches, and timing.

Internationalized Domain Name

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

Top-Level Domain