Dear all, Please find below the notes and action items from today’s meeting on Thursday, 18 May 2023 at 12:00 UTC. Kind regards, Ariel, Steve, and Emily Notes and Action Items - IDNs EPDP Call – 18 May 2023 Action Items Action Item 1: Leadership to draft text reflecting discussion with suggested recommendations for C4, C5, and C6. The EPDP Team’s next conversation can focus on that draft text. Action Item 2: Staff to forward to the EPDP Team the communication to the SSAC regarding next Thursday’s call. Action Item 3: Staff to check on status of ICANN77 meeting schedule and when it will be posted publicly. Notes Welcome and Chair Updates * Thanks to those who joined the webinar yesterday. Attendance was somewhat light, possibly explained by the APAC-friendly time. * No requests yet to extend public comment deadline. Deadline is currently 5 June. * The GNSO has approved a tool and process for working groups to conduct self assessments during the life of the E/PDP. A self-assessment survey will be opened on Monday next week and remain open for three weeks. Members, alternates, and participants will receive an email with details and a link to the survey. Continued IDN table harmonization (charter questions C4, C5, C6) Recap from previous meeting * Slide 3: Charter Questions: C4, C5, C6 * Last week, the EPDP team went over what harmonization is and why it matters * C4 in brief: Should harmonization be required * C5 in brief: If harmonization is needed how should it be accomplished * C6 in brief: Focuses on how IDN Tables should be effectuated * Slide 4: Focus on Charter Question C4 * Slide 5: Recap of Deliberations for Future Applications – C4 * The Team understands what Harmonization is and why it is important (i.e., avoid inconsistent identification of variants). * Members need to check with their groups, but from a principles level, most seem to support the conservative approach of requiring that applicants/Registry Operators must harmonize their IDN tables for a given gTLD and any variant gTLD(s). * Question: Have EPDP Team members had a chance to speak to their groups to confirm what was heard on last week’s call? * Comment: RySG has not yet reached a conclusion, but is leaning towards being conservative and supporting harmonization. * Comment: ALAC has not yet had a chance to discuss. * Slide 6: Focus on Charter Questions C5-C6 * Slide 7: Recap of Deliberations for Future Applicants – C5/C6 * The Team considered the proposals from the staff paper (i.e., Extend Each IDN Table, Extend Label Check Process) and the anecdote from Michael. * However, while the Team recognized these as viable options, initial reactions seemed to indicate a preference for allowing Registry Operators to determine how to achieve harmonization. * The Team reviewed the evolution of IDN Table Format RFCs (RFCs 3743, 4290, and 7940) and what was shared is that at least some registries do not take IDN tables as inputs into their systems. Rather, they export the IDN tables to meet ICANN requirements. If XML were required, it would mean that registries would have to change how they export the table; wouldn’t change system inputs. * Anecdote from Zuan Zhang re: how Chinese Domain Name Consortium (CDNC) coordinates/manages Chinese IDN table * Concerns expressed about considering adoption of 7940 or Reference LGR - both appear outside scope of C6. * Comment: For 7940, it was suggested that the group examine with respect to other CQs. Continued deliberations * It was noted that the way that registries implement the system is based on the system/software they use. The question is whether tables should be in a machine readable format when shared through IANA. RFC 7940 was suggested as a requirement because that format allows those using IANA tables (ICANN during review, other registry operators while designing their own tables) to process tables less manually and through machines. The advantage is that the LGR format the rules are formally specified, leaving a smaller chance of misinterpretation. It allows for more automatic operations. One could do harmonization in automated manner. * Comment: Perhaps discussion of RFC 7940 does not belong under C6, but it might be appropriate to discuss under other charter questions. Note that the resources required to do the shift to a requirement that ROs move to be consistent with RFC 7940. * Comment: It’s not just time to make the change. It also takes money because engineers will need to do the work. The return on investment is not worth it. * Comment: As reviewed last week, many IDN tables are in TXT. It would be a significant undertaking for ROs. * Question: With RFCs, is there a point in time that RFCs become a technical requirement? * Comment: RFC are of multiple types. The early ones (RFC 3743 and 4290) are informal. The later one (RFC 7940) is standards track, meaning it has been recognized as a standard by the IETF. * Comment: If the RFC is in a contract or a policy, the contracted party has to follow it. Otherwise CPs don’t have to follow. * Comment: In general, all IETF outputs are recommendations for standards. It is up to the businesses and organization to make a judgment call to make them “requirements." In our industry, we adopt IETF standards via consensus policies or contract obligations * Comment: In the context of IDN tables format, this is the current IANA procedure where RFC 7940 is the recommended format https://www.iana.org/help/idn-repository-procedure * Slide 8 – Discussion Questions – Existing ROs * For existing IDN Tables already implemented by existing ROs Should harmonization be a requirement? * For existing IDN Tables already implemented by existing ROs, if the answer to question 1 is yes, should any specific harmonization mechanism be recommended? * For existing IDN Tables already implemented by existing ROs, should the XML format, as recommended by RFC 7940, be required retroactively for already implemented IDN Tables? * One way to look at it is two divide it into two parts. Harmonization seeks to address a security challenge. The first part of the question is should harmonization be done going forward to avoid registration issues. The second part is to deal with existing registrations. * When we are talking about existing ROs we are talking about single TLD, not variant sets. But if variants are part of consensus policy, it would be inconsistent not to require harmonization in existing TLDs. Harmonization needs to be consistent across the name space. Regarding existing registrations, barring significant security concerns, perhaps we can provide the opportunity for grandfathering, which is common practice in certain types of situations. * Clarification: For existing ROs going forward, harmonization would be a requirement. Grandfathering would only apply to existing registrations. * Question: Have there been security challenges with IDN registrations at the second level using IDN tables that are not harmonized? * Response: There has been anecdotal evidence that has been published. The .epic/.epic example was published a few years back. Org has not done an analysis of how many cases of issues exist. * Question: Do we have data or how many ROs currently harmonize IDN tables? * Response: This is not tracked because it is not currently a requirement. * Comment: A suggested data point mentioned in the charter is how many ROs use the LGR format, but that doesn’t necessarily mean that they do harmonization. * Comment: The idea is that the existing registrations could be grandfathered – if the registered domain is dropped, the RO would have to enforce harmonization going forward. * Comment: Grandfathering is a pretty common practice. The alternative is to force harmonization, meaning that a registration is not renewed. * Comment: In the Verisign case, renewal is different from deletion and re-registration. Typically, renewal will just extend the existing registration. When re-registered, it is subject to the registration rules at that time. * Question: should it be a limited period for grandfathering? Does grandfathering appliy to registered names prior to a nominated date? In other words, what are the parameters for grandfathering? * No additional comments. * Comment: It would be useful to have some research on second level domains that currently exist but would be denied under harmonization rules, with counts of affected domains grouped by script or language, so we have an idea of how many domains would be grandfathered, and how much of a security issue it might be. * Response: While it resources might not be available for this data set, there are anecdotal examples that can be reviewed, * Question: 1. For new IDN Tables to be submitted by existing ROs (e.g., as part of the variant gTLD application), should harmonization be a requirement? 2. If the answer to question 1 is yes, how to manage any potential inconsistency with any of the ROs’ already implemented IDN Tables? * Response: It makes sense to have a consistent approach. When we talk about harmonization it should apply to all ROs, existing and new. * Question: One of the aims of harmonization is to make sure that the registries are using tables consistently. There are different levels of consistency. If we have one practice for existing domain names and a different rule for new ones, does that make sense from a consistency perspective? * Response: We are not talking about all ROs being consistent and having identical implementation. We are talking about having a consistent approach to variants that the RO applies in a single name spaces. This type of consistency will address security concerns. But the ROs will be able to adopt their own policy while following the contractual and other obligations. Action Item 1: Leadership to draft text reflecting discussion with suggested recommendations for C4, C5, and C6. The EPDP Team’s next conversation can focus on that draft text. AOB * Next week’s call: Charter Questions C1, C2, C3 and discussion with SSAC subject matter experts about Phase 1 recommendations. * A communication was sent to staff supporting the SSAC mapping CQs and recommendations that touch on early input from the SSAC as well as relevant SSAC advice. This enables them to prepare for the conversation in advance. Action Item 2: Staff to forward to the EPDP Team the communication to the SSAC regarding next Thursday’s call. * Donna will present the revised timeline to the GNSO Council next Thursday, in the context of the Board request for information on efforts that have a dependency on the next round. * Leadership has previously raised the idea of dedicated face-to-face time during Phase 2 work. That will be included in the slides for the Council presentation. Exact timing and location are to be determined, but a 6-month lead time is anticipated. Leadership team would like the meeting to take place in the APAC region. Action Item 3: Staff to check on status of ICANN77 meeting schedule and when it will be posted publicly. 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/>