[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #81 - 11 May 2023

[Emily Barabas]

Dear all,

Please find below the notes and action items from today’s meeting on Thursday, 11 May 2023 at 12:00 UTC.

Kind regards,

Ariel, Steve, and Emily


Notes and Action Items - IDNs EPDP Call – 11 May 2023

Action Items

Action Item 1: EPDP members to encourage their community colleagues to attend the webinar on 17 May at 11:00 UTC.
Notes
Welcome and Chair Updates

  *   Donna is on vacation this week. Justine will be chairing the call.
  *   SOI update – Justine is the ALAC representative to the SubPro IRT.
  *   Thanks to all for remembering to attend the call one hour earlier. Meetings are now taking place at 12:00 UTC.
  *   There is a community webinar scheduled for Wednesday next week (17 May) at 11:00 UTC. The webinar will focus on getting the community up to speed on Initial Report recommendations.
Action Item 1: EPDP members to encourage their community colleagues to attend the webinar on 17 May at 11:00 UTC.

  *   The EPDP Team call on 25 May will be a discussion with SSAC. This is the second engagement session held with the SSAC and this EPDP.
IDN table harmonization (charter questions C4, C5, C6)
Background and presentation on what harmonization is:

  *   Slide 3: Charter Questions C4, C5, C6
     *   Note: mutually coherent = harmonized
     *   Harmonization Core Question - C4) Should the second-level IDN tables offered under a TLD, including IDN variant TLDs, be required to be mutually coherent? If yes, how should existing registrations which may not meet the “mutually coherent” requirement of second-level IDN tables be addressed?
     *   Harmonization Mechanism - C5) The Staff Paper suggests maintaining a common set of harmonized second-level IDN tables for all IDN variant TLDs and then (a) choosing all these IDN tables to offer for all IDN variant TLDs, or (b) choosing a relevant different subset of IDN tables to offer for each different IDN variant TLD. Are the above suggested methods in the Staff Paper sufficient for IDN table harmonization purposes? Should any additional implementation guidance be provided for a registry?
     *   Harmonization Mechanism - IDN Table Format - C6) Should Registry Operators be required to use the machine readable LGR format as specified in RFC 7940 for their second-level IDN tables? Or should Registry Operators have the flexibility to resolve the harmonization issue so long as it can predictably and consistently produce the same variant labels, albeit with different disposition values, across the same-script IDN tables?
  *   Slide 4: What is an IDN Table
     *   An IDN Table is used by a registry operator to represent second-level rules under a gTLD for validating IDN labels for registration, calculating variant labels, and determining disposition values of variant labels.
  *   Slide 5: What is Harmonization?
     *   Summary: Ensure that the variant relationship between any two given second-level labels is consistently defined across all of the IDN Tables offered by a gTLD and its variant gTLD(s).
     *   Clarification - the purpose is to ensure that the set of labels in a set is consistent throughout the TLD, no matter what table used. Disposition values might be different.
     *   Additional information: How does the RO know which table to use? If a IDN label is being requested, the EPP needs to come up with a language tag parameter which informs the registry of the intended language to use and therefore the associated table.
  *   Slide 6: Example Output
  *   Slide 7: Why is harmonization needed? – Potential consequence of current practice
     *   There is no current requirement for harmonization and no requirement for ICANN org to cross reference the different IDN tables for a gTLD.
     *   As a result, the second-level variant label set produced for a requested second-level label may be inconsistent when different IDN Tables are used. Variant labels may be permitted for registration by different registrants as distinct labels under the same gTLD.
     *   Question: When a registrant wants a SLD, does the registrant choose the IDN Table, and can this be abused?
     *   Response: The registrant is probably not able to choose. The registrar will choose which IDN table to be used. It shouldn’t be possible to misuse. The registry should take care that inconsistent registrations are not possible.
     *   Response: Anecdotally from one registry, there are different ways that registrars select the language. In some cases, the registrar does this on behalf of the registrant. It is up to the registrar to validate the string and the language.
  *   Slide 8: Example Output: Consequences Without Harmonization
     *   Clarification: Harmonization is not a tool that creates variant relationships. If a registry decides to create variant relationship, that is one choice. A second choice is harmonization, which is about making these relationships consistent.
     *   Response: The relationship between 643 and 689 is established by the Arabic script community. The script community had also established the relationship between 629 and 6C3. Unicode has encoded these two letters K and T in Arabic and K and T in Urdu as different code point. As far as the script community is concerned, the two Ks are the same and the two Ts are the same. This is also the same in reference LGRs for the Arabic script. If they are designing an Arabic table, the use the Arabic K and T and when designing the Urdu table, they use the Urdu K and T. If you don’t harmonize, you can end up with two identical strings with two different registrants.
     *   Response: That is a design choice of the reference LGRs. The comment above is implying that the registries need to harmonize with the reference LGR, which is a different issue. Harmonization the context of the current discussion is only about practices within IDN tables.
     *   Response: If there are two variants, the motivation of harmonization is to address a security problem where if two identical strings under a TLD, they should either be registered by the same registrant or be blocked. If they are registered by different registrants there is a security risk. Who identifies what is a variant label? We can take this from the relevant script community. That is based on their understanding about what is the same or not. What we are suggesting is that a variant set is based on a community’s recommendation.
     *   Question: Are there going to be collisions resulting in the process of harmonization?
     *   Response: This question gets into how this should be implemented. There are two ways to implement – data driven or process driven. In one case, one could keep the same IDN tables and change the process. Alternately, you keep the process the same and update the tables. This will be discussed later.
     *   Comment: We are talking about two different things. One is harmonization. The other is on what variant relationships should be included in variant tables at the second level. That is the prerogative of the RO. That is outside the question of C4.
     *   Response: In some ways this is correct. However, there is one more impact of harmonization. Even when registries are doing it, there will be some impact on ICANN’s review of IDN table. When designing the IDN table for Arabic, ICANN would also need to look at other IDN tables using Arabic script. Designing IDN tables may be a separate process, but it will eventually have some influence on the design itself because of the downstream process.
  *   Slide 9 – How are IDN Tables Harmonized
     *   Currently no standard process for harmonizing IDN tables. Staff paper suggested two possible methods: Extend each IDN table or Extend label check process.
     *   Reference to cross-language and cross-script should be removed from this slide.
     *   Ultimately how a registry solves the harmonization requirements will depend on the systems.
     *   These two methods are presented as examples without a suggestion on picking one or another. It could vary from registry to registry. Different methods could lead to the same result, so the requirement could simply be that harmonization is required.
     *   These are possibilities but registry platforms predate harmonization requirements. Registries will need to take the requirements and design architecture to solve for that. How it is achieved can be left to the registries to design. It will be counterproductive to mandate design decisions.
  *   Slide 10 – Anecdote on Harmonization Practice – Shared by Michael Bauland
     *   Clarification: The variants for all labels are stored in a canonical way in a database. At each registration, the canonical form is compared against the database to see if the label should be blocked.
     *   For canonical calculations, the canonical label could even be mixed script. It is not shown to anyone. It’s not used for anything else, only for harmonization on IDN tables. It is not comparable to the primary label.
     *   The EPDP Team is also seeking inputs from other registries and registrars about what they currently do with respect to harmonization. This provides additional context for the group as they consider policy recommendations.
  *   Slide 11 – If Harmonization becomes a policy requirement – potential outcomes:
     *   ICANN org be authorized to review ALL IDN Tables offered by a gTLD and its variant gTLDs in a holistic manner
     *   ICANN org may reject an IDN Table if the variant label set of a given code point is not consistently produced
  *   Slide 12 – IDN Table Formats
     *   Comment: These are ways to represent rules of a table. Up to this point, when published the IDN table is an artifact to represent the rules of the registry but does not inform how the registry logic works. Regardless of format of the output, it is a plain output. Disagree with the text in the slide: “LGR processing tools can be developed to help registries automatically harmonize IDN Tables in XML format.” You still need to parse the XML rules and have to build a machine read it. Some registry databases predate XML. You can’t conclude that using the XML table format is a way to ensure harmonization.
     *   Comment: Agreement with the above comment. The processing tools that exist are helpful for registries that already uses XML format. If you are not using XML format, these tools won’t help. It may not be easy to build the XML format standard in existing software. Some registry platforms may not implement XML format.
     *   Comment: Moving to XML format won’t solve the harmonization per se, but a transition over time may be helpful. If you want to transfer a domain between registries and the registries use different formats, a manual intervention is needed. XML is future looking.
     *   Response: Adoption of RFC 7940 is outside the scope of charter question C6.
     *   Comment: Transferring between registrars might not be a problem as long as the registry remains the same. Registrars look to the registry to use the IDN tables. There is a different charter question focused on transfers.
     *   Additional information about the tools:
        *   option that you feed in a TXT format and get a XML format.
        *   provide a function to show an HTML representation of the XML.
        *   open-source, code is available in GitHub, so it is not necessary to start from scratch.
     *   IDN Tables are a representation, not a reflection of how the system works. Registry systems don’t take IDN Tables as input.
     *   IDN tables don’t drive the logic of the registry platform. In the registry platform, there are specific rules that are applied. There is a hierarchy of rules that need to be represented. The IDN tables themselves are visually independent, but there is logic behind the analysis that takes place.
     *   C6 is not necessarily the impetus for moving things to XML format in service of harmonization. If harmonization is prescribed, efficiency on top of that could be achieved via XML.
  *   Slide 13 – Anecdote on IDN Tables – shared by Zuan Zhang
  *   Slide 14 - Discussion Questions – Future Applicants
     *   Discussion Question 1: Should harmonization be a requirement? In other words, should it be a requirement that the variant relationship between any two given second-level labels is consistently defined across all of the IDN Tables offered by a gTLD and its variant gTLD(s)
     *   Discussion Question 2: If the answer to question 1 is yes, should any specific harmonization mechanism be recommended? Specifically, should the Reference LGR, including the Common LGR, be recommended as a reference for developing IDN Tables by future applicants?
     *   Discussion Question 3: Should the XML format, as recommended by RFC 7940, be required for IDN Tables to be submitted by future applicants?
        *   Question: Does this refer to Charter Question C6? As presented it does not summarize the CQ. Question 3 is presented without the context of the charter question, which explains what we are trying to solve for.
        *   It was agreed that question 3 more accurately a sub-question under question 2.
     *   Comment: Harmonization is seeking to address security concerns. But we can’t think about harmonization in a vacuum. There is also usability, which is connected to the principle that behavior may be different. Registries are leaning towards being conservative, but do not have a definite answer. They are leaning towards making a positive statement on harmonization. Registries feel strongly that it should be left to registries to determine how to solve for harmonization.
     *   Some support expressed for the idea that the WG should recommend harmonization but not how registries do it at a technical level.
     *   Suggestion that the EPDP Team might want to develop an oversight mechanism to address security and stability issues.
     *   Comment: We shouldn’t add to existing requirements for backend testing.



Emily Barabas
Policy Development Support Senior Manager
Internet Corporation for Assigned Names and Numbers (ICANN)
Phone: +31 (0)6 84507976
www.icann.org<http://www.icann.org/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20230511/59abb0f9/attachment-0001.html>