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

Proposed Agenda for LD PDP Working Sessions during ICANN84
by Saewon Lee Oct. 21, 2025

Oct. 21, 2025

Dear LD PDP WG, Thank you to the members who submitted edge cases for the stress test during our working sessions at ICANN84. Accordingly, please find below the proposed agenda for LD PDP WG Working Sessions 1 & 2 during ICANN84 on Saturday, 25 October 2025 (10:30-12:00 IST & 13:15-14:30 IST): 1. Welcome and SOIs 2. A Brief Overview of LD PDP 3. Recap of Meeting #23 4. Recap of Meeting #ef Overview of LD PDP 5. A Brief OverviewRecap of Meeting #22 * Key Outcomes and Action Items 1. Continue Review of Draft Preliminary Recommendations<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgdu…> 2. Stress Test 3. Continue with Charter Topic Deliberations * Charter Question 4 * GPI/HR Impact Assessment 1. Table of Contents for Initial Report 2. Next Steps 3. AOB We look forward to seeing you all soon! Kind regards, 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

ICANN84 GNSO Policy Briefing and ICANN84 Policy Outlook Report
by Julie Bisland Oct. 17, 2025

Oct. 17, 2025

Dear All, On behalf of the GNSO Team, I am happy to share the ICANN84 reports below are available for download. * GNSO Policy Briefing: http://go.icann.org/gnsobriefing * Policy Outlook Report: https://go.icann.org/outlook84 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

FINAL REMINDER: Edge Cases
by Saewon Lee Oct. 16, 2025

Oct. 16, 2025

Thank you for your kind message, Sandra. We look forward to meeting you too! Dear ALL: Pursuant to Action Item #1 below, this is a final reminder to submit any edge cases to the list by tomorrow, 17 October, to facilitate discussions during ICANN84. 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> From: Sandra Rodriguez via Gnso-latin-diacritics <gnso-latin-diacritics(a)icann.org> Reply-To: Sandra Rodriguez <sandra.rodri2340(a)gmail.com> Date: Wednesday, October 15, 2025 at 1:30 PM To: anil Jain <asdj1990(a)gmail.com> Cc: "GNSO-Latin-diacritics(a)icann.org" <gnso-latin-diacritics(a)icann.org> Subject: [Gnso-latin-diacritics] Re: Outcomes, Action Items, and Notes for 15 October Meeting #23 Dear John/Saewon/Michael, Anil Thank you for the kind reminder. I'm very happy to meet with the team in person at ICANN84. Warm Regards from El Salvador. Sandra Rodriguez. El mié, 15 de oct de 2025, 8:48 a. m., anil Jain via Gnso-latin-diacritics <gnso-latin-diacritics(a)icann.org<mailto:gnso-latin-diacritics@icann.org>> escribió: Dear John/Saewon/Michael, Please consider following edge cases for ICANN 84 sessions: Edge cases: 1. If LD of Brand ASCII in not allocated/delegated, but somebody else ( Other than present Brand TLD owner) apply LD of brand TLD with Permission from Brand TLD owner can it be considered? 2. If there are changes in LD due to changes adopted in language by a country/ region, what will happen to already delegated LD TLDs ? Similarly is registry of a brand LD TLD lose Brand legally, should we transfer/ Reserve LD TLD to new owner? Anil Sent from my iPad On 15 Oct 2025, at 3:34 PM, John Emery via Gnso-latin-diacritics <gnso-latin-diacritics(a)icann.org<mailto:gnso-latin-diacritics@icann.org>> wrote: Hello LD PDP WG, Aa a reminder, we will not be having a session next Wednesday due to travel for ICANN84, so we will see all of you in person or virtually for our Dublin meetings. Also, please focus your current energy on sending edge cases to stress test our recommendations to the mailing list by Friday 17 October at the latest. Below are the meeting #23 outcomes, action items, and notes: [OUTCOMES] * PR #35 and #36 determination made that that an entity other than the one holding the remaining IDN gTLD in the ASCII/Latin diacritic gTLD set for at least 10 years following the removal * Consensus on language of PR #39, 40, 42, 43, and 44 as written in slide [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/UAD…> number 17 and 18 * Consensus to delete IG #41.2 as it does not apply to the Latin script case [ACTION ITEMS] * WG members to share edge cases on list by 17 October to discuss during ICANN84. * Leadership and Staff to include the term second level in PR#39.1 and 39.2 * Leadership and Staff to reword IG #41.1 to accurately convey its meaning [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #22 a. Key Outcomes and Action Items * Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/UAD…> with majority in favor of option 2 for PR 35-38 with updated text in the slides * PR 35 Agreement still needed on how many years we would like to block this following removal * Discussion between 2 years and 10 years (like IDN ccTLDs) and given that application rounds take approximately 2 years from application to delegation. * Consensus reached at 10 years 1. Action Item for ICANN84 * The goal of the ICANN sessions is to deliberate any remaining recommendations on the preliminary report, then work through stress tests. * Examples of stress tests in the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/UAD…>. Please propose additional examples by 17 October 3. Review of Preliminary Draft Recommendations [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/10PiKG0grWcN2…> * Graphic created for understanding ASCII/LD Set for second level and compared LD PDP or EPDP-IDNs in the slides. Either way, both need to belong to the same entity even if they are not variants of each other * PR 39 not requiring something, just defining what we mean with a LD domain set as we will need the definition for later recommendation for the required same entity principle in later recommendations * 39.1 a second level label and all its variants and 39.2 all other TLDs * Implied here is that any variants of the TLDs will have the same considerations because of existing policies. A TLD and all its variants and LD TLD and any of its variants will have similar second-level rules. In stress test examples we want to look into how this works at the second level. * PR# 40 should there be an LD domain set which includes the ASCII/LD and their variants at the top level. * Variants go into stress test example. If you have a LD/ASCII TLD set no variant exists with current LGR. This could change in the future, but we can’t have any variants of that TLD set. If there were to be variants, we might need rules for that, but that is not needed at the moment. * IG #41 wording is slightly wrong as we do not want to restrict the set itself, just the number of domains within the set that can be allocated. The set is already defined by the LGR and variant rules, no need to change the size of the set. * What we want to do here is set a maximum number of domains within the set that are allocatable at the same time. With IDNs there could be lots of domains within it, the registry should not allow the activation of tons of domains within a set and we want a similar rule here * Sarmad: 41.2 question for IDN-EPDP the scope was much broader than Latin Scripts. Given this is limited in scope, whether this is something that is needed or desire to do this, or how this is motivated. * This is likely not needed in the Latin script community. But the initial background in IDN was coming from the Han script community. Discussion of removing 41.2 because automatic activations are not a topic for Latin it can be removed. * PR#42 slide [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/UAD…> number 18 we need to have a new recommendation which is not covered by IDN-EPDP that this extends to all domains within the LD/ASCII domain set as they are not variants. This must be extended to both domain sets * No issues with wording presently what was called grandfathering and now called exempted. The wording here is a bit stronger not speaking about exempted and is flagged. * It is a transient thing, even in the IDN-EPDP there was no timeframe, they can keep their domains for however long they want to. This could also be forever as there is no force in making one remove or change. Stayed close to IDN wording, but with changes as it is not variants. * PR #43 agree not to increase the number of exempted domains. The only direction is to remove exempted cases and there should not be the possibility to increase them. * PR #44 this discussed harmonized ASCII/LD gTLD set and there were no objections to the language 4. Next Steps 5. AOB 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> _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics(a)icann.org<mailto:gnso-latin-diacritics@icann.org> To unsubscribe send an email to gnso-latin-diacritics-leave(a)icann.org<mailto:gnso-latin-diacritics-leave@icann.org> _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics(a)icann.org<mailto:gnso-latin-diacritics@icann.org> To unsubscribe send an email to gnso-latin-diacritics-leave(a)icann.org<mailto:gnso-latin-diacritics-leave@icann.org>

1 0

Outcomes, Action Items, and Notes for 15 October Meeting #23
by John Emery Oct. 15, 2025

Oct. 15, 2025

Hello LD PDP WG, Aa a reminder, we will not be having a session next Wednesday due to travel for ICANN84, so we will see all of you in person or virtually for our Dublin meetings. Also, please focus your current energy on sending edge cases to stress test our recommendations to the mailing list by Friday 17 October at the latest. Below are the meeting #23 outcomes, action items, and notes: [OUTCOMES] * PR #35 and #36 determination made that that an entity other than the one holding the remaining IDN gTLD in the ASCII/Latin diacritic gTLD set for at least 10 years following the removal * Consensus on language of PR #39, 40, 42, 43, and 44 as written in slide<https://icann-community.atlassian.net/wiki/x/UADgGg> number 17 and 18 * Consensus to delete IG #41.2 as it does not apply to the Latin script case [ACTION ITEMS] * WG members to share edge cases on list by 17 October to discuss during ICANN84. * Leadership and Staff to include the term second level in PR#39.1 and 39.2 * Leadership and Staff to reword IG #41.1 to accurately convey its meaning [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #22 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/UADgGg> with majority in favor of option 2 for PR 35-38 with updated text in the slides * PR 35 Agreement still needed on how many years we would like to block this following removal * Discussion between 2 years and 10 years (like IDN ccTLDs) and given that application rounds take approximately 2 years from application to delegation. * Consensus reached at 10 years 1. Action Item for ICANN84 * The goal of the ICANN sessions is to deliberate any remaining recommendations on the preliminary report, then work through stress tests. * Examples of stress tests in the slides<https://icann-community.atlassian.net/wiki/x/UADgGg>. Please propose additional examples by 17 October 3. Review of Preliminary Draft Recommendations<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgdu…> * Graphic created for understanding ASCII/LD Set for second level and compared LD PDP or EPDP-IDNs in the slides. Either way, both need to belong to the same entity even if they are not variants of each other * PR 39 not requiring something, just defining what we mean with a LD domain set as we will need the definition for later recommendation for the required same entity principle in later recommendations * 39.1 a second level label and all its variants and 39.2 all other TLDs * Implied here is that any variants of the TLDs will have the same considerations because of existing policies. A TLD and all its variants and LD TLD and any of its variants will have similar second-level rules. In stress test examples we want to look into how this works at the second level. * PR# 40 should there be an LD domain set which includes the ASCII/LD and their variants at the top level. * Variants go into stress test example. If you have a LD/ASCII TLD set no variant exists with current LGR. This could change in the future, but we can’t have any variants of that TLD set. If there were to be variants, we might need rules for that, but that is not needed at the moment. * IG #41 wording is slightly wrong as we do not want to restrict the set itself, just the number of domains within the set that can be allocated. The set is already defined by the LGR and variant rules, no need to change the size of the set. * What we want to do here is set a maximum number of domains within the set that are allocatable at the same time. With IDNs there could be lots of domains within it, the registry should not allow the activation of tons of domains within a set and we want a similar rule here * Sarmad: 41.2 question for IDN-EPDP the scope was much broader than Latin Scripts. Given this is limited in scope, whether this is something that is needed or desire to do this, or how this is motivated. * This is likely not needed in the Latin script community. But the initial background in IDN was coming from the Han script community. Discussion of removing 41.2 because automatic activations are not a topic for Latin it can be removed. * PR#42 slide<https://icann-community.atlassian.net/wiki/x/UADgGg> number 18 we need to have a new recommendation which is not covered by IDN-EPDP that this extends to all domains within the LD/ASCII domain set as they are not variants. This must be extended to both domain sets * No issues with wording presently what was called grandfathering and now called exempted. The wording here is a bit stronger not speaking about exempted and is flagged. * It is a transient thing, even in the IDN-EPDP there was no timeframe, they can keep their domains for however long they want to. This could also be forever as there is no force in making one remove or change. Stayed close to IDN wording, but with changes as it is not variants. * PR #43 agree not to increase the number of exempted domains. The only direction is to remove exempted cases and there should not be the possibility to increase them. * PR #44 this discussed harmonized ASCII/LD gTLD set and there were no objections to the language 4. Next Steps 5. AOB 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>

4 3

Proposed Agenda for Meeting #23
by Saewon Lee Oct. 14, 2025

Oct. 14, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #23 on Wednesday, 15 October 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #22 * Key Outcomes and Action Items * Action Item for ICANN84 1. Review of Draft Preliminary Recommendations<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgdu…> 2. Next Steps 3. AOB Kind regards, 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

Post Call | Latin Script Diacritics PDP | Wednesday, 08 October 2025
by Devan Reed Oct. 8, 2025

Oct. 8, 2025

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 08 October 2025 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AgDaGg> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2025>. 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. With kind regards, Devan

1 0

Outcomes, Action Items, and Notes from Meeting #22 on Wednesday, 8 October 2025
by John Emery Oct. 8, 2025

Oct. 8, 2025

Dear LD PDP WG, Please see attached the Outcomes, Action Items, and Notes from Meeting #22<https://icann-community.atlassian.net/wiki/x/AgDaGg> on Wednesday, 8 October 2025. [OUTCOMES] * The blocking of a TLD removed from the root zone should only be in case it is applied for by a different entity. If it is to the existing set then there doesn’t need to be a waiting period. In case a different entity applies for it then we need some rules * Suggestion to create a special reserve name category for subsequent rounds to block or not allow those strings like other categories. Not reserved fully, only if outside of the set. [ACTION ITEMS] * Staff to add language indicating that there need not be a waiting period of the same entity applies for the TLD and treats it as a set * Staff to discuss with LT language to create a special reserve name category to block dropped names outside of the set if not the same registry operator [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #21 * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AgDaGg> and discussed how action items were resolved * PR 35-38 continued discussion * Two major points to discuss: 1) how and if LD applicants can voluntarily remove one or multiple TLDs (conditions for that) and 2) what provisions are necessary to remove them? * Reviewed EPDP-IDNs P1 Recs 8.10-8.13 for reference and discussed the implications for the LD PDP * If we remove the base ASCII likely all other IDN diacritic TLDs would have to be removed from the root zone * Trying to solve something that is already solved in the agreement. Upon termination there is transition. Normal case the TLDs will be transitioned to another operator, and if not possible then it could go to EBERO in exceptional circumstances. Against having a new exception in this case. * We are not trying to make additional rules to retire a TLD, make additional restrictions to remove a root TLD zone, to make the rules if for some reason some of these TLDs get removed from the root zone what are the consequences for the set. * Joseph, ICANN org, this is in the RA that ICANN can look to the public interest and look at usage at the 2nd level to determine whether the TLD will be transitioned to a new TLD operator, EBERO, or terminated. This applies to all TLDs not just .brand. * There is a possibility to remove the ASCII and retain one of the diacritic TLDs is one of our options. IDN EPDP solution is that the whole set needs to be removed and they have a different base because all the variants depend on the primary one. Our case the TLDs are more or less independent and put in a set * We need additional rules or policies when one or more TLDs get removed from the root zone for any reason. Due to the structure of the set, we are making those recommendations to make it harder to remove TLDs with consistency of the set * Discussed difference between EPDP-IDNs and LD PDP * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AgDaGg> that if the set is dissolved as a total the TLDs are independent and no relation needs to be upheld * We can look at the ccPDP4 (10 years) or the RA for .BRAND for those provisions (2 years following expiration date). Two situations these policies we could use for our case when a TLD within the set is removed so a TLD applied for outside of the set again. * Sarmad, ICANN org, pointed out key differences with our TLDs in both of these cases the recommendations are generally talking about a TLD which when it goes away and potentially comes back there is no possible confusing TLD that is delegated at the same time. In our case, if one remains and one is dropped, then they will be two competing TLDs that can confuse the end users. Second, in some ways even though they are joined by base ASCII these strings are not .BRAND and not ccTLDs. * Trying to find a solution where one TLD is removed from the set, should that be directly available or some rule that blocks it for some period of time? * As a part of ccTLD and IDN EPDP where decisions were taken in both working groups were a different situation. In LD PDP it is possible to delegate LD and diacritic to separate registry operators. Practically there is a likelihood of user confusion. That is what mainly the deselection and string sim panel is looking at. If either ASCII or diacritic is removed for any reason. We might be delegating to a registry operator for a period of time and we have to restrict it for some time for confusingly similar issues * Discussion TLDs should not ever be delegated ever to this removal. If we can’t say forever 10 years * If one of those TLDs gets removed even with PDP active different entities could apply for it, but it will likely get rejected due to string sim review panel. Suggestion for a long as we can afford. * This blocking should only be in case it is applied for by a different entity. If it is to the existing set then there doesn’t need to be a waiting period. In case a different entity applies for it then we need some rules * Discussed how to deal with this through three options in the slides<https://icann-community.atlassian.net/wiki/x/AgDaGg> * 35 and 36 can be applicable at the same time. They are not mutually exclusive. 35 is about the removal of the ASCII gTLD and 36 is about the LD label. In the IDN-EPDP that would be the primary and variant * The option that allows for keeping 1 of the TLDs and retains some additional rules for keeping some rules for the same registry. * This is extremely unlikely case if there are lots of registrations then it is unlikely to be dropped. * Option 2 gaining consensus, but have some rationale of making it 2 years vs. 10 years. Unless we understand the rationale it would be hard for us to choose either way. Would need a number of years here * Restriction not meant for the same registry operator wanting the TLD again. It would be for any entity outside of the set, even though it would be likely they would be rejected from the string sim panel, but we cannot be certain. This TLD is safe from being used outside the set when it has been used in the set before * Unlikely this would happen because it is expensive and a lot of work. * There could be some kind of rule that would ensure that it would be caught in string sim eval rather than x number of years * Sarmad, suggestion to create a special reserve name category for subsequent rounds to block or not allow those strings like other categories. Not reserved fully, only if outside of the set. 3. Review of Preliminary Draft Recommendations<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgdu…> 4. Preparation for ICANN84 5. Next Steps 6. AOB 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 #22
by Saewon Lee Oct. 8, 2025

Oct. 8, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #22 on Wednesday, 8 October 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #21 * Key Outcomes and Action Items 1. Review of Draft Preliminary Recommendations<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgdu…> 2. Preparation for ICANN84 3. Next Steps 4. AOB Kind regards, 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

Re: Outcomes, Action Items, and Notes from Meeting #21 on Wednesday, 1 October 2025
by Saewon Lee Oct. 2, 2025

Oct. 2, 2025

Dear LD PDP WG, Pursuant to Action Item 1 from Meeting #21 re updating PR #32, the language (adding clarity for LD PDP and the ASCII/Latin diacritic gTLD set labels) and footnote (details on GPs per RZ-LGR procedure) have been incorporated into the PR doc. here in p.31: https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgdu… Regarding concerns about the updated RZ-LGR not fully maintaining full backward compatibility, particularly related to identifying exceptions during Public Comment and allowing for potential exemptions in cases where gTLDs may be affected, please note that recommendations addressing these issues are currently in place (PR #33 and IG #34), extending and maintaining alignment with EPDP-IDNs. Here are the additional preliminary recommendations for your reference (pp.31-32 in the PR doc. above): Preliminary Recommendation 33: Consistent with Final Recommendation 8.8 from the EPDP-IDNs Phase 1 Final Report, in the unexpected event where a proposed update to the RZ-LGR is unable to retain full backward compatibility for validating any delegated gTLDs and their corresponding ASCII or Latin diacritic gTLD label(s) (if any), the relevant GP must call out the exception during a Public Comment period and explain the reasons for such exception. The Public Comment period should also include the elements in the following Implementation Guidance. Implementation Guidance 34: Consistent with Implementation Guidance 8.9 of the EPDP-IDNs Phase 1 Final Report, the GP explanation should identify security and stability risks (if any), as well as possible actions to mitigate the risks associated with allowing a delegated gTLD and its corresponding ASCII or Latin diacritic gTLD label(s) (if any) to be exempted. There should also be an assessment, conducted by ICANN org, of the potential impact of exemptions on registries, registrars, registrants, and end-users, as well as proposed measures to reduce the negative impact. As part of the assessment, ICANN org should facilitate a timely dialogue between the registry operator of the exempted gTLD, relevant function(s) in ICANN org, the GP, other experts and affected parties. Notwithstanding the recommendation to exempt affected gTLDs, in the event security and stability risks are identified, ICANN org and the affected registry operator should discuss possible measures to minimize the risks that would result in minimal disruption to registries, registrars, registrants, and end-users. Relevant rationales will also be added to the doc. now that the WG has established PR #32, and I hope this language addresses the concerns raised during yesterday’s call. Best regards, 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, October 1, 2025 at 11:19 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 #21 on Wednesday, 1 October 2025 Dear LD PDP WG, Please see attached from today’s meeting: Outcomes, Action Items, and Notes from Meeting #21 [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/NgD…> on Wednesday, 1 October 2025 [OUTCOMES] * Option 2 decided for preliminary recommendation 32 with some slight changes to be completed * Determined positions on multiple issues raised in the preliminary recommendations draft [ACTION ITEMS] * Staff and Leadership to update Preliminary Recommendation 32 * Staff and Leadership to update Preliminary Recommendation 35 and 38 [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #20 * Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/NgD…> and discussed how action items were resolved * Changes to IG 11 and PR 14 discussed * Updated language to PR 32 explained, do we use the adjustment or leave it as covered in the IDN-EPDP * Sarmad would the GPs automatically understand that this is ASCII/Latin diacritic gTLD label sets suggestion to clearly specify it is through this policy of the same entity. * Discussion of the meaning of full backward compatibility. Should not say to NOT make them variants, there could be a relationship in the RZ-LGR. If they are variants and they are blocked we must retain full backward compatibility to allow for allocated ASCII/LD not impacted by this. * PR 32 Discussion of exemption terminology and it could make this more readable for Public Comment and Board deliberations. Understand the intent of the WG with exemptions. * With variants we want full backward compatibility and there could be allocated variants that are blocked. Perhaps it makes sense to explain this a bit more in the rationale * Suggestion for Sarmad to keep the same language. This is something GPs and IPs need to look at on a case-by-case basis. Making things very strict or requiring backward compatibility might diverge from previous recommendations. * “A Latin Generation Panel” not “The Latin Generation Panel” suggested 3. Review of Preliminary Draft Recommendations [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/10PiKG0grWcN2…> * PR 35 does not need guidance as it is up to the registry operator to decide for itself. No need for guidance. Consistency will likely be implied given that there will likely never be a case as it is a set * Without knowing the way, the registries are using the TLDs it is problematic to force something on them without a need to force it on them * The only question here is for any change in the root or registry ICANN needs to consider the interest of the registrant, there is no need to get rid of the domains that have more users. * Add a sentence to PR35 the choice of the TLD to be kept should be done with due diligence with all parties: registrars and registrants duly considered. * Practical implications of this means that the application or contract about a set will be changed to a contract with a single TLD just as any IDN single TLD and fees would be the same as a standard single TLD. * In our context it is the same as if you were to drop a variant from a TLD set. It would be available again but would be rejected due to being visually confusingly similar. * PR 35 needs some fine-tuning based on practical consequences. But the original question of remaining TLD being defined in some way. Contrary to IDN-EPDP our TLDs are not related in the sense regarding the RZ-LGR they are basically able to exist on their own. The reason is LD is not like variants where it is subject to ASCII though they act as a set. * Possible issues for edge cases explored for dropped TLDs * There is no reason why we could have a possibility of dropping one if there are registrants. Also, there may be no case where a diacritic would NOT be confusingly similar. * What is the current policy dropping a standalone TLD? It will be sent to EBERO unless there are no registrations. Redo PR35 in that we should not also allow dropping TLDs with registrations voluntarily * Ensure these recommendations are consistent with current policies as we revise the recommendation * Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/NgD…> for understanding the 2nd level sets for Phase 2 * Same entity requirements for all domains; ASCII/LD domain set. * Extensive discussion about what domains require the same entity on the 2nd level and our decision was only the exact same label will require the same entity by our rules. Only the LD PDP requires this to be the same entity. The variants are a consequence of the IDN-EPDP and not something we actively decided here. * Robust discussion of confusingly similar situations where there are not variants. Amadeu will follow up on the list. 4. Preparation for ICANN84 5. Next Steps 6. 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

Transition of TLDs upon termination
by Amadeu Abril i Abril (CORE) Oct. 2, 2025

Oct. 2, 2025

Hi all, resending this, hopefully to the correct email address this time… The quyote I made fromthe TLD Agreement on the transition to EBERO is … welll, not that accurate, to be polite with myself ;-) Even if the Agreement says so in an indirect way in 2 places. The relevant section is 4.5, dealing with transition (to anotehr Registry or, if there is no such possibility to EBERO: this is implied but clear). And, more relevant for the exception it contains, in section 4.5 of the Spec 13, the specification for Brand TLDs(which typically have no third parties as registrants, but this is not always the case). I could only find Spec13 in PDF and one that does not allow me to paste here its content in readable way. So, jst check and savour the difference in the very end of the section. It grants an excpetion to Brand TLDs, saying that YtLD will NOT be transitioned to another registry (which includes EBERO) but simply deleted from the root and NOT delegated again for at least 2 years. but… but all this unless ICANN decides that there are public interest reasons for transitioning it. Which is the rule for all other non-Spec13, tLDs. and the reasning for this public interest is, indeed, the existance of independnet registrants and domains. This is not explained inthe text (how could lawyers earn their lives, if things were clear???) but everybody involved would tell you that this is what it nmeans. So, the rule for ICANN on a tLD Agreement termination is transitioning, aka redelegation. If not possible for any reason,then EBERO as an intermediate step. Direct deletion, i.e. not transitioning, is only posible for special TLDs without third party registrants(Brand TLDs, and not in all cases). Same should apply to our Latin Diacritic sets. I submit againthat NO voluntary deletion of any of the TLDs should be allowed, if domains for third party registrants doexist. And in the exceptional case in whcih ICANN must terminate the ASCII TLD for whtever reason…. well….. I cannot see how it could be simply be deleted without any transitioning priod… involving the same Registry or, sending all the TLDs to EBERO for quite some time. Amadeu

2 1