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

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. 7, 2025

Oct. 7, 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. 1, 2025

Oct. 1, 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

Proposed Agenda for Meeting #21
by Saewon Lee Sept. 30, 2025

Sept. 30, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #21 on Wednesday, 1 October 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #20 * 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

ICANN84 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland Sept. 29, 2025

Sept. 29, 2025

Dear all, With ICANN84<https://meetings.icann.org/en/meetings/icann84/> just around the corner, please take a moment to read the information below for a seamless and successful meeting. ICANN84 key dates: * Prep Week will take place virtually 13 - 15 October 2025. * Deadline for IN-PERSON registration is 24 October 2025. * ICANN84 will take place in Dublin 25 - 30 October 2025. On-site registration will not be available. Registration for ICANN84 does not automatically create a user account on sched.com. Instructions and guides to register as well as personalize your schedule can be found on these pages: * Visit this page to REGISTER: https://meetings.icann.org/en/meetings/icann84/ * General information about Dublin, hotels, transportation and rates, and links to food options can also be found here * The ICANN84 Schedule: https://icann84.sched.com/ * Instructions for personalizing your schedule can also be found here There will be no calendar invitations sent, as the meeting schedule allows you to download all sessions of interest to your individual calendars A reminder to review the Participation Tools page and update Zoom * All sessions that use Zoom rooms, access details will be available 24hrs prior. * Visit the Participation Tools page<https://meetings.icann.org/en/remote-participation> for links to download the latest version of Zoom for access to the ICANN Meeting sessions. * Please see the ICANN Meeting VIRTUAL AND IN-PERSON PARTICIPATION GUIDES in the blue box on the right side of the page for more information on how to get the most out of the virtual meeting tools. * If participating on-site, please read the Frequently Asked Questions here<https://meetings.icann.org/en/meetings/icann84/#faq>. Links to Bookmark ICANN84 Meeting Schedule<https://icann84.sched.com/> ICANN84 GNSO Remote Participation Wiki Page<https://icann-community.atlassian.net/wiki/x/FYBUGQ> GNSO Session agendas<https://icann-community.atlassian.net/wiki/x/AYCMFQ> For all GNSO meeting-related queries, please email us at: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> and we will be more than happy to assist! Kind regards, GNSO SO/AC Support team -- 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

Re: Outcomes, Action Items, and Notes from Meeting #20 on Wednesday, 24 September 2025
by Saewon Lee Sept. 24, 2025

Sept. 24, 2025

Dear LD PDP WG, Please find attached the revised slide deck from today’s meeting. The timeline in slides 10-11 for the drafting of the initial report and confirming them as stable should have been Oct-Nov. 2025, not Sep-Oct. 2025. These slides can also be accessed on the wiki here: https://icann-community.atlassian.net/wiki/x/HADgGg Kind 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, September 24, 2025 at 10:39 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 #20 on Wednesday, 24 September 2025 Hello LD PDP WG, Please see attached. Outcomes, Action Items, and Notes from Meeting #20 [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/HAD…> on Wednesday, 24 September 2025 [OUTCOMES] * Determined positions on multiple issues raised in the comments [ACTION ITEMS] * Staff and Leadership to update IG 11 in line with Sarmad’s comments “as an extension if necessary” * Staff and Leadership to updated Rec 14 footnote referencing Next Round AGB instead of 2012 round * All WG members to review the rationales that have been added to the Preliminary Draft Recommendations [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/10PiKG0grWcN2…> and think of scenarios to stress test * Staff and Leadership to Rec 28 should have an added rationale explaining how the set would be subject to Category 1 Safeguards [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #19 * Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/space…> and discussed how action items were resolved * Three options for PR 7, discussion of reasoning for “existing gTLD” * Discussion not a mission and purpose for the existing TLD but for the whole set * Corresponding discussion for minimizing operational complexity for LD domains * Applicant will describe the justification of the need (to whom?) Wording for Must vs. May * Mission/Purpose is just a sentence, why you want that TLD, to whom, and how you will try to minimize the risk of TLDs that are inherently visually confusingly similar. Cannot only apply to new TLDs, also existing * Ariel: Implementation approach will have a variant string evaluation where a panel would review the justification questions. Applicants will justify the need for that, and a panel will evaluate the responses. Possibly there would be something similar like the IDN-EPDP for LD PDP. * Decision was to provide some additional justification for mission/purpose * Agreement with option 1 As-Is Consistent with EPDP-IDNs * IG 11 instead of having our own report, would be to use the decided process of IDN-EPDP and combine this research and add the sentence outlined in the slide. * Sarmad: Instead of requiring an extension, may suffice to use exactly the same process. “As an extension if necessary” * Rec 14 Footnote: Ariel: raised that referencing the next round AGB instead of 2012 round as there is language defining “established institution” and best to reference the latest language. * Rec 13 the term “discount” Ariel: confirmation from org that there is no issue or misunderstanding with the term “discount” the Board already adopted this rec. So if the group decides to continue to use the term “discount” there are not concerns. The recommendation has been adopted but not implemented yet, so still in a pending status. 3. Update on LD PDP Timeline * Reviewed timeline in slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/space…> and we are about 3 months ahead of schedule * Unfortunately, this means that we would have problems incorporating this into the Next Round as Board adoption of AGB is at ICANN84 and final opportunity would be December 2025, and launch is April 2026. * Always a slim chance that it would be possible to include this in the AGB, but we did a great job and had record pace and topics were discussed thoroughly. This will be rules for eternity, but better to get the policy right * Discussions broadly on the risk of an application for diacritics in this round of having the application rejected or delayed. * Steve: sounds simple to allow for an LD set to be applied for and put in limbo, but it is not simple. Every string gets integrated into the string similarity process including external elements that run on cycles. All these are on a schedule in the program. Can’t put a string in limbo if the outcomes of this PDP are unclear. Generally, hesitant to broach the subject of the next round, it was still a moonshot even if it was wrapped up in a month. * Any ideas how to make this possible can be shared on the mailing list as it remains nearly impossible * There are possibilities for application processes changing along the way, so the WG should not be set back and proceed at a normal pace and not be impacted by what is happening here. 4. Review of Preliminary Draft Recommendations [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/10PiKG0grWcN2…> * Staff has begun adding the rationales in the document and provide comments and suggestions via mailing list. * Comment from Bill on Rec 18 and if it was in conflict with recommendation 13? It was clarified and the comment can be resolved as they are talking about fees with application vs. ongoing fees for operation of TLDs * Rec 28: Category 1 Safeguards all TLDs in the set. If there is a problem with it, we can remove it. * Ariel, the set is subject to the same safeguard public interest commitments. That is the intent of the PDP recommendations. This type of string is specialized. Based on AGB drafting process it is not a specialized application. The set is a subject to this. * Put something in rationale that the set would be subject to this. * Rec 32 discussion of RZ-LGR defines the characters and variant relationships. It could theoretically be possible to add variants. That is out of scope for our purpose. If such changes happen in the future, the generation panel needs to be aware of this problem that would not be possible with new ruling that retains full backward compatibility * Sarmad: this is already in IDN-EPDP Phase 1. Question is repeating that recommendation here, is there any additional angle that is being added here? Or if that is already part of Phase 1? This may be redundant. Is there anything specific added in this context? * The way this is written does not look at variants, it is existing gTLDs * Ariel: put forward a recommendation on what the group intends to achieve rather than RZ-LGR as it does not seem too related. Gets convoluted 5. Next Steps 6. 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>

1 0