Dear LD PDP WG, As requested by the WG today (during Meeting #36<https://icann-community.atlassian.net/wiki/x/AYA7PQ>), and to prepare for Meeting #37, please find below the summary of the Public Comment submissions for PR39 below: Preliminary Recommendation 39 Building on an ASCII/Latin diacritic gTLD set as defined in Preliminary Recommendation 1, an ASCII/Latin diacritic domain set is defined to include: 39.1 a label and all its variants within a given TLD, as determined by the second-level LGRs for that given TLD; and 39.2 the same labels and all their variants across all other TLDs within the ASCII/Latin diacritic gTLD set. Public Comment Submissions 1. “Supporting the recommendation as written” Category – in general, these comments are not introduced for discussions during WG meetings; but this one was introduced since ALAC requested the WG’s acknowledgement. * Requestor: ALAC * Request: LD PDP WG to acknowledge the need for an end-user understanding of the second-level. * Problem: Many LD PDP safeguards operate invisibly to end-users, particularly where diacritic domain names are withheld and while often beneficial, the unexplained unavailability may undermine consumer confidence. Clear and accessible explanations are encouraged when domain names are blocked or unavailable due to LD PDP-related rules. * LD PDP WG Action: Awareness only – No action needed at this time. 1. “Support the recommendation with wording change” Category * Requestor: ICANN org * Requests: * Add the term “second-level” before the word “label (to be updated to string)” in the Output language to enhance clarity, rather than relying on footnotes or rationale. * With respect to [Figure 3] in the rationale section<https://gnso.icann.org/sites/default/files/policy/2026/draft/initial-report-...>, add explanatory text to assist readers who may be unfamiliar with the WG’s deliberations regarding the definition of the ASCII/Latin diacritic domain set. * Problem for both requests: Current policy and rationale language need to provide further clarity, especially for those readers who may be unfamiliar with the WG’s intentions and deliberations. * LD PDP WG Action: Consideration and action (revise/add language to provide clarity, if appropriate) required 1. “Significant change required” Category * Requestor: ICANN org * Requests: * WG to consider whether the existing output (together with PR1) aligns with the introduction and management of IDN variant TLDs and the requirements are sufficient to mitigate potential risks effectively. * WG to assess whether the definition and requirement of an ASCII/Latin diacritic domain set needs alignment with the ASCII/Latin diacritic gTLD set, and determine whether additional measures should be developed to mitigate potential registrant and end-user confusion. * Problems: * Both PR1 and PR39 definition may depart from the longstanding principle of introducing and managing the IDN variant TLDs. * Definition and treatment of the ASCII/Latin diacritic labels at the second-level may differ from the top-level – including grouping of the labels as a set which does not exist at the second-level and top-level strings that may not be part of a Variant TLD set – and these differing approaches for the sets at the top and second-levels may cause confusion. Moreover, Case 1.3<https://gnso.icann.org/sites/default/files/policy/2026/draft/initial-report-...> illustrated in the rationale for PR40 needs to be reconsidered (no rules for non-variant second-level labels within the ASCII/Latin diacritic gTLD sets and to leave such decisions to the discretion of the gTLD registry operators). * LD PDP WG Action: Consideration and action (revise/add language to provide clarity, as appropriate, and/or change policy intent, if necessary) required. As shared during the call, please still review the public comments in their entirety through the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4BE...>, which is also updated each week with WG discussion notes, key outcomes/consensus, and responses to the comments received. The updated language resulting from each meeting can also be accessed here: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-E... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1BTAlq9vGEVVeI...> Thank you all for your thoughtful contribution. Much appreciated, Saewon From: John Emery via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> Reply-To: John Emery <john.emery@icann.org> Date: Wednesday, May 20, 2026 at 10:31 AM To: "gnso-latin-diacritics@icann.org" <gnso-latin-diacritics@icann.org> Subject: [Gnso-latin-diacritics] Outcomes, Action Items, and Notes from Meeting #36 Dear LD PDP WG, Please find attached the outcomes, action items, and notes from Meeting #36 [OUTCOMES] * Agreement on IG11 to allow for flexibility in timeline and research requirements for ICANN org * WG Agreed on High-Risk Scenario for conservatism principle * PR 7 no objection to being consistent with EPDP-IDNs [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1L...> and the proposed draft after each WG Meeting and provide input, if any. * Leadership and Staff to update rationale to clarify PR35 and PR36 * Leadership and Staff to update rationale for PR50 work to clarify rationale to cover questions raised by org. * Leadership and Staff to outline options forward for conservatism on proliferation based on the WG votes * WG to review PR1, PR39, PRs40-41. [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #35 a. Key Outcomes and Action Items * Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> for action items and LT/Staff proposed new language for Amadaeu’s suggestion to not allow the coexistence of ASCII and LD gTLDs independently 3. Review of LD PDP Initial Report Public Comment * Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> to look at PR35 and PR36 discussion of a 10-year cool off period and EBERO discussed. Query to org on problem with these recommendations * Ariel asked about when the 10 year cool off period begins, if it transitioned to EBERO then it will not be applicable, so she is trying to seek clarification on this * PR35/36 Micahel’s clarification As long as the set remains intact there is no need for any cool off period then EBERO is a special RSP, required to handle these TLDs as a set. No new registrations will be possible in EBERO. It was to require the same entity principle across all TLDs. The 10 year cool-off period only applies if one TLD is removed from the Root Zone. If the TLDs remain with EBERO no one could apply for the TLDs as they still technically exist. * IG11 discussed on slide [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> 13. Question about the timeline as it has not happened for EPDP-IDNs yet. From ICANN’s perspective the timeframe component expectation and joint research effort. Which of these need to be prioritized? The timeframe or the joint research? * The WG utilized the same timeframes as EPDP-IDNs so they seemed to suggest a sensible path forward to adjust the first timeline for the LD PDP to match EPDP-IDNs then research could be done in parallel. * Agree the flexibility of the wording both in the timeline to align the research and in the requirement that it does not have to be done together, but may be done together if deemed sensible. So, where practical/possible. * PR50 discussed, there was a request for clarification on the rationale on the intended scope of the requirements and level of detail needed. * Ariel added that the question is whether the WG is asking org to explain every single recommendation in the outreach, more focused on the same-entity principle for the necessary outreach. She wanted to make sure they were aligned on the policy position point as it is vague. Essentially, is it a high-level or detailed dive? * Suggestion to have rationale expanded to explain information requirement is bounded by "...and their potential impact on dispute resolution proceedings" and is not completely open-ended. * High Risk Scenario outlined in the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> and proposed language from Amadeau outlined as Recommendation X to not permit independent applications. * The intention of the three suggestions are not mutually exclusive, all three can be implemented, none of them, or any combination. All three suggestions can be voted on to allow for the conservatism principle. Support for Amadeau’s suggestion coalesced to not permit independent applications. * Outcomes for conservatism principle: * 1) Rec X: 3 in favor 2 against * 2) Rec language for high-risk: 2 in favor 2 against * 3) Rec language for additional justification 7.5: 1 in favor 3 against * Went through the Public Comment Review Tool [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1L...> looking at PR14 looking at .Brand trademark law characteristic for 14.3. A brand should not be required to own a ™ for all variants of its mark. 1) delete the mischaracterized ™ law in the rationale or 2) The EPDP-IDNs language currently in the recommendation * Discussion about PR14 for trademarks and brands and the Rationale language in question: “Thus, under trademark law, the rights are attached to one, distinct mark limited to an exact match.” * the current language could be updated to become as below to be consistent with EPDP-IDNs: “...its applied-for ASCII gTLD and Latin diacritic gTLD(s) that constitute the set are identical considered the same to registered trademarks owned and used by the registry operator or its affiliate.” * Change would be consistent with EPDP-IDNs seems to solve the problem, but suggestion to reach out to IPC. * Proposed work plan outlined on slide [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> 20 and asked WG to review PR1, PR39, PRs40-41 * Preview for second level discussion for next week and would be left to the discretion of the registry All the best, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>