October 2025 - Gnso-latin-diacritics

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

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

Oct. 1, 2025

Dear LD PDP WG, Please see attached from today’s meeting: Outcomes, Action Items, and Notes from Meeting #21<https://icann-community.atlassian.net/wiki/x/NgDgGg> 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<https://icann-community.atlassian.net/wiki/x/NgDgGg> 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<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgdu…> * 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<https://icann-community.atlassian.net/wiki/x/NgDgGg> 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

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

Oct. 1, 2025

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 01 October 2025 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/NgDgGg> (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