Dear all,

Please find below the notes from the IDNs EPDP Working Session (2 of 2) at ICANN74. Please note that as this meeting was primarily background/foundational information oriented, the recording should be consulted for details.

Best,

Ariel, Emily, and Steve

Notes – IDNs EPDP Call – 15 June 2022

Welcome and Opening Remarks

Helpful to provide level-set before we talk about 2nd level implications, since it will not be the same as the top-level.

Foundational Presentation: IDN Tables at Second-Level

Slide 2 - Terminology
Slide 3 - Rules for ASCII Domain Name Labels
Slide 4 - Domain Name Mnemonics in ASCII
Slide 5 - Domain Name Mnemonics in ASCII - top-level
Slide 6 - Internationalized Domain Name (IDN) Labels
Slide 7 - Objective of IDN Tables
Slide 8 - What Does the IDN Table Do?
Slide 9 - What is an IDN Table?
Confirmation that IDN tables at the second-level are more discretionary than in nature versus the top-level, which is fixed against the RZ-LGR.
Two registries that serve the same language and/or script, may have different tables.
As tables are established by the registry, how are they managed? Responsibility of the registry. This will be covered when the registries/registrars talk about their practical experiences.
In reality, the tables generally have a lot of commonalities.
Slide 10 - Evolution of IDN Table Formats
Slide 11 - Example of IDN Table in RFC3743 Format
Slide 12 - Example of IDN Table in RFC4290 Format
Slide 13 - Example of IDN Table in RFC7940 Format
Slide 14 - Why the XML Format?
Question - must the old format tables be deleted with the new formats? Answer - it is a business decision. All three are supported by ICANN.
For RZ-LGR, is the XML schema consistent? Consistent with relevant RFC.
Slide 15 - Who Develops the IDN Tables?
How are security and stability problems mitigated? ICANN Org reviews and resolves with registry operator. Once mutually agreed to, it is captured in Exhibit A.
“Any” security and stability problems, without context, is perhaps an unrealistically high bar. Iterative process between ICANN Org and RO tries to mitigate as best as possible.
Slide 16 - Example: Mini Latin Script IDN Table
Slide 17 - Example: Mini Latin Script IDN Table, cont.
Slide 18 - Activating Variant Labels at the Second Level
Slide 19 - Harmonizing Multiple IDN Tables Under TLDs
Slide 20 - Harmonizing Multiple IDN Tables under TLDs
Slide 21 - Example: The Need of Harmonization for IDN Tables
Slide 22 - Example: The Need of Harmonization for IDN Tables, cont.
Slide 23 - Example: The Need of Harmonization for IDN Tables, cont.
Slide 23 - Example: The Need of Harmonization for IDN Tables, cont.
Slide 24 - Example: The Need of Harmonization for IDN Tables, cont.
Slide 25 - Reference Label Generation Rules (LGRs)
Question - Practically, is it possible to combine the tables, or do you just have common ruleset? Answer - there are actually three tables (e.g., Latin, Cyrillic, and combined).
Slide 26 - Background of IDN Table Review
Slide 27 - IDN Table Review Tool

Share Practice with regard to IDN Management at Second-Level & IDN Table Implementation

Given the presentation, what are the practical experiences for registries and registrars? For instance, are there implications for different IDN tables.
Dennis Tan (Verisign) - There are more than 100+ IDN tables. Different languages and scripts will require different rules (e.g., simplified and traditional Chinese).
Policy for variants, for many years, is to simply block the variants.
Question - as there isn’t a high level of variability between IDN tables across different ROs, does that represent coordination? Answer - Generally, there are more commonalities than differences. Deviations generally just limited to a handful of characters/letters and rules.
Suggestion, maybe some data can be gathered from IANA repository.
Question - is there direct interaction with language communities? Answer - the consultation did take place, but many years ago. Context is that the tables were leveraging existing work, not starting from the ground up.
Question - what’s the discussion like for the ICANN Org and RO security and stability review? Answer - can generally be limited b/c tables are consistent. However, ongoing discussions on how make the process more consistent and transparent.
Security and stability is a dynamic property. What was previously secure and stable may not hold forever.
For registrars, what is the applicability for the IDN tables?
At least in one experience, the registrar does not implement the IDN table. The registrar will send the check to the RO, who is able to provide the authoritative answer. In essence, the registrar can rely on the registry’s validation (e.g., sending via EPP, a domain check command).
As a back-end RSP, will need to work with RO to determine which IDN tables the client wants to deploy. In some cases, will leverage existing IDN tables.

AOB

None

Steven Chan 

Senior Director, Policy Development Support & GNSO Relations

Internet Corporation for Assigned Names and Numbers (ICANN)

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536 

Email: steve.chan@icann.org

Skype: steve.chan55

Mobile: +1.310.339.4410

Find out more about the GNSO by visiting: https://learn.icann.org/

Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO

Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar