- Gnso-latin-diacritics - lists.icann.org

ICANN86 Notes, Outcomes, and Action Items
by John Emery June 10, 2026

June 10, 2026

Dear LD PDP WG, It was great to see many of you in person at ICANN86 and many thanks to those of you who joined remotely. Please see below the attached notes, outcomes, and action items from the ICANN86 LD PDP WG meeting. [OUTCOMES] * WG agreement on updated language for PR 1 * WG agreement on PR40 that the 2nd level must also retain the same entity principle. [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> and the proposed draft after each WG Meeting and provide input, if any. * Staff and Leadership to review PR X to ensure that the language in the rationale accounts for a case where an LD can be applied for if one currently has an existing ASCII would account for this in PR 3. * WG to consider the Board input on PR18 and PR19 to discuss at the next LD PDP WG meeting * [NOTES] 1. Welcome and SOI Updates 2. Remembering Alan Barrett, Board Liaison to the LD PDP WG * The WG and the Board paid tribute to the life and legacy of Alan Barrett. A tribute to him and his accomplishments can be found on slide 5<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…> 3. Recap of Meeting #37 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…> and the ICANN Board raised an issue that Alan discussed to the Board before his untimely passing. * The Board members present Amitabh Singhal and Chris Buckridge gave an update to the LD PDP WG on PR18 and PR19 related to fees. In sum, the Board has concerns about recommendations related to fees, which are at the discretion and in the remit of ICANN org. Furthermore, there was a clear debate and discussion surrounding EPDP-IDN’s Final Recommendations 7.4 and 7.5 that they would be a non-precedent setting recommendation. By following these specific recommendations, it appears to the Board that the LD PDP is following the precedent. There is a distinct difference between EPDP-IDNs, which were intended to incentivize adoption of IDN variants, while LD PDP is meant to be an exceptions process and should take a more conservative approach. Given the untimely passing of Alan, the Board would need additional time for a formal response, but they noted this should not hold up the work of the LD PDP. This informal meeting conveys the essence of the Board’s concerns on this topic. * PRX recommendation discussed and the intended meaning is that it is not possible to have them operated separately and/or applied for separately. * Bill: concerned that someone might already have an ASCII diacritic they would need to effectively make a new application. We need to get the wording clear that it's allowable * Saewon: We do have a separate recommendation on applicants submitting a new application for an already existing gTLD but this point can be added to the rationale. Preliminary Recommendation 3: Consistent with Final Recommendation 3.2 of the EPDP-IDNs Phase 1 Final Report, a future gTLD registry operator wishing to apply for a corresponding ASCII gTLD or Latin diacritic gTLD(s) of their existing gTLD must submit an application during an application round. * PR 1 discussed allowing for a more expanded scope beyond the early unicode decomposable table discussed on slide <https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…> 10. Emphasis placed on the deep deliberations that took place to get this point. * PR 39 updated language noted * Figure 3 updated to make it more user friendly and the same entity principle as outlined in the slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…>. * Query from Ariel about harmonization of LD and Variant tables. Michael responded that there is this requirement, but this case is still theoretically possible. The LGRs harmonized does not mean they have to be the same. They just have to be consistent. * Edge case examples of Figure 3 outlined in the slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…>. * PR 40 and case 1.3 discussed as previously this was allowed to be the registry to decide. If at the TLD it has to be the same entity, then at the 2nd level the registry could just decide. This could cause more user confusion. Consequence during last call is that all 2nd level labels must now belong to the same entity as well 4. Review of LD PDP Initial Report Public Comment * Saewon outlined the Human Rights Impact Assessment based on the Public Comment with a summary in the slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…> but she encouraged all to review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> * She gave an overview and highlighted for the proposed path forward based on the HRIA and GPI Public Comments, strengths were many, but there were a few improvements for the Final Report. This was a lot related to implementation or future work. Much was not relevant to the current working group, it could be detailed further within the final report of the HRIA 5. Review of Proposed Table of Contents for Final Report 6. Consensus Call Process Reminder 7. Work Plan and Next Steps 8. AOB Thank you, 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>

1 0

Same entity on 2nd level
by Tapani Tarvainen June 3, 2026

June 3, 2026

Thinking of the test.domain vs tést.domain scenario, I find myself concluding that enforcing the same entity principle on 2nd level domains is not viable. Confusion potential is real, but as it already exists for extant TLDs, ASCII as well as IDN ones, and we cannot do anything about those, can or should we enforce stricter rules for our case? Same entity requirement on 2nd level could also have some undesirable side-effects. What would happen if cafe.quebec and café.quebec were already extant with different registrants when .québec is applied for? Should that block .québec application? Or should the policy have some kind of grandfather clause? I don't see why café.quebec and cafe.quebec would be less likely to cause confusion than cafe.québec and café.québec. If anything the latter should be safer simply because people using .québec are more likely to pay attention to accents. Likewise, sakki.fi, säkki.fi and šakki.fi (all extant domains with different registrants) are unlikely to confuse Finnish speakers, and others are less likely to use .fi domains. I guess we could require applicants to document their policy in this regard, perhaps including that they must alert registrants to the issue, but I would not insist on strict same entity principle on 2nd level. I remain, however, open to persuasion. :-) -- Tapani Tarvainen

7 11

ICANN86 Policy Outlook Report / GNSO Chair Blog
by Julie Bisland June 2, 2026

June 2, 2026

Dear All, On behalf of the GNSO Team, I am happy to share the ICANN86 Policy Outlook Report and the GNSO Chair Blog: * GNSO Chair Blog: https://www.icann.org/en/blogs/details/the-gnso-council-welcomes-you-to-ica… * Policy Outlook Report: https://go.icann.org/outlook86 Happy reading! With kind regards, Julie -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) 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=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> 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_grou…>

1 0

Sad news
by Louis Houle May 29, 2026

May 29, 2026

Hi everyone, Sad news, Our collegue Alan Barret passed away <https://www.icann.org/en/announcements/details/icann-announces-the-passing-…> on 28 May 2026 following a diagnosis of late-stage cancer. More news here; https://www.icann.org/en/announcements/details/icann-announces-the-passing-… -- Louis Houle Président Un Québec branché sur le monde UQBM.Quebec 581 994-9955

4 3

Post Call | Latin Script Diacritics PDP | Wednesday, 27 May 2026
by Devan Reed May 27, 2026

May 27, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 27 May 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AoC2R> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-latin-diacritics@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/EwDVBg?atlOrigin=eyJpIjoiMWI2M…>. Thank you. Kind regards, Devan Policy Team Supporting the GNSO

1 0

Outcomes, Action Items, and Notes from Meeting #37
by John Emery May 27, 2026

May 27, 2026

Hello LD PDP, Please find attached the outcomes, action items, and notes from meeting #37. There will be no call next week on 3 June, so we will see all of you in person or online in Seville. [OUTCOMES] * IG 11 agreement to delete “necessary” * Rec X agreement from the group to include, with some adjustments to wording necessary * PR 1 WG agreed with option 2 to utilize the expanded character scope with a limit * WG Agreement to require same entity principle at the 2nd level [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> and the proposed draft after each WG Meeting and provide input, if any. * Staff and Leadership to adjust wording of Rec X and add a rationale to clarify * Staff and Leadership to update PR 1 especially on 1.1, 1.2, and the unicode table based on WG decision to go with option 2 * Staff and Leadership to use concrete examples for PR 39 and explain the broader principles * Staff and leadership to update WG agreement to require the same entity principle at the 2nd level [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #36 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AoC2R> for key outcomes and action items * IG 11 was updated to give ICANN a bit more flexibility as outlined in slide<https://icann-community.atlassian.net/wiki/x/AoC2R> 7. ICANN org agreed with the edits. WG agreed to eliminate “necessary” * Option for Conservatism for Rec X was discussed and an overview given in the slides<https://icann-community.atlassian.net/wiki/x/AoC2R> with examples included. If you want to apply for ASCII and LD as a set, it is just saying they can’t be run by a separate registry. * Rec X will be written in the rationale to ensure that the meaning will be conveyed to give additional certainty and conservatism * Suggestion to replace “applicant” with “applications” in Rec X but overall agreement that some new wording will be needed * Agreement from the group for Rec X to move toward conservatism * PR 1 discussion on slide<https://icann-community.atlassian.net/wiki/x/AoC2R> 11. RZ LGR Option 2 is okay as it only includes characters from that, so there is no increase to the RZ-LGR. Whether there are other SSR issues, we cannot think of any, but will check back on that issue * Concern overall for a question for defining a diacritic and the Unicode approach was option 1, option 2 is the expanded character. * Broader discussion on all these character points have been used on the IDN tables, it is not about the code points, it is the definition of a diacritic, it is an arbitrary point by this group. All these points are in the RZ-LGR and the 2nd level. It is a question of what we consider a diacritic and the conservatism principle does not apply here and SSR is not an issue here * Ariel weighed in and noted that the WG has worked hard to the conservatism principle as a total package. There are already other steps introduced to make the application for LD/ASCII sets more conservative as a whole. * For PR 1 the group agreed to option 2 * PR39 overview given in the slides<https://icann-community.atlassian.net/wiki/x/AoC2R> with a robust discussion of Figure 3 from simple to complex cases. Even the experts are having trouble with the figures. It is better to explain the core principles for variants and ASCII/LD TLDs. If this group is confused, then likely we would need real examples * The general idea is that every label and all variants need to be in the same entity set. We also have to include all those labels in all the other TLDs and do a transitive closure on the variants. * PR39 and PR 40 continued for discussion at the 2nd level, and there is a comment from ICANN that the ASCII/LD has to be same entity at the top level, at the 2nd level there is not this requirement and it is left open to the registry operator * This is a crucial question about the main mandate to allow LD/ASCII TLD sets if we reduce the risk of user confusion. * Ultimately, for the DNS the 1st and 2nd level we may have contradictory policies. This does not reduce confusion, it actually increases confusion. With all of this, it is going away from the mandate that this group was given in the Charter. Amadeu referenced his email to his systematic review of PR39 and PR40 and the contradictory nature of allowing registries to determine the 2nd level. The primary concept is avoiding user confusion and not registry freedom. In general, this goes along with conservatism. * Examples given in the slides<https://icann-community.atlassian.net/wiki/x/AoC2R> 18 and 19 that 2nd level should not be left to registry discretion. This is inconsistent with the general rule for TLDs. Same entity principle should hold at the top level but at the 2nd level it is up to the registry and both ICANN and Amadeu argue it is inconsistent. * The group discussed this and was persuaded that the 2nd level should be consistent with the top level same registry principle for an LD/ASCII set. It is only enforcing policy rules for ASCII/LD sets. Proposal to set a high bar, not to prohibit. Theoretically a registry could do it differently. * Same entity principle there are very good reasons to enforce it at the 2nd level as this would create user confusion. * For the TLDs the diacritics should be the same, then it should be consistent as a registry at the 2nd level * General agreement that the same entity principle should apply at the 2nd level. Some disagreement as to whether there should simply be a very high bar for exceptional cases, or an outright ban. * Discussion that the solution may be a footnote that registries could apply for an amendment which is part of recommendation 42. 3. Review of LD PDP Initial Report Public Comment 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>

1 0

Proposed Agenda for Meeting #37
by Saewon Lee May 26, 2026

May 26, 2026

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #37 on Wednesday, 27 May 2026, at 13:00 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #36 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB This week, the WG is expected to finalize discussions for PR29 and continue with discussions for PRs. 1, 39, and 40-41 as they relate to the public comments received. Please review the Public Comment submissions in their entirety through the Public Comment Review Tool here: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1…> Much appreciated, Saewon Saewon Lee Policy Development Support Manager for GNSO Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 (310) 463-5541 Email: saewon.lee(a)icann.org<mailto:saewon.lee@icann.org> Skype: saewon.lee.icann Website: www.icann.org<http://www.icann.org>

1 0

Summary of Public Comment Submissions for PR39
by Saewon Lee May 22, 2026

May 22, 2026

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-4B…>, 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-… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1BTAlq9vGEVVe…> Thank you all for your thoughtful contribution. Much appreciated, Saewon From: John Emery via Gnso-latin-diacritics <gnso-latin-diacritics(a)icann.org> Reply-To: John Emery <john.emery(a)icann.org> Date: Wednesday, May 20, 2026 at 10:31 AM To: "gnso-latin-diacritics(a)icann.org" <gnso-latin-diacritics(a)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/1lsDs0nV1…> 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/AYA…> 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/AYA…> 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/AYA…> 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/AYA…> 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/1lsDs0nV1…> 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/AYA…> 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>

3 4

Post Call | Latin Script Diacritics PDP | Wednesday, 20 May 2026
by Devan Reed May 20, 2026

May 20, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 20 May 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AYA7PQ> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-latin-diacritics@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/EwDVBg?atlOrigin=eyJpIjoiMWI2M…>. Thank you. Kind regards, Devan Policy Team Supporting the GNSO

1 0

Outcomes, Action Items, and Notes from Meeting #36
by John Emery May 20, 2026

May 20, 2026

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<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> 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 * Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AYA7PQ> 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<https://icann-community.atlassian.net/wiki/x/AYA7PQ> 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<https://icann-community.atlassian.net/wiki/x/AYA7PQ> 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<https://icann-community.atlassian.net/wiki/x/AYA7PQ> 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<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> 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<https://icann-community.atlassian.net/wiki/x/AYA7PQ> 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>

1 0