June 2026 - Gnso-latin-diacritics

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