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<mailto:steve.chan@icann.org> Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=o7Auz997kA-HPv9PHJCjFVZw7Pgo8krw4MxfqCwBrIU&e=> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNSO&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=kWw4fQPNjw2lVKy1UjTxS2F0BmjEAzaDFWNmsYywbmE&e=> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_group...>