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/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgduN... 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@icann.org> Reply-To: John Emery <john.emery@icann.org> Date: Wednesday, October 1, 2025 at 11:19 AM To: "gnso-latin-diacritics@icann.org" <gnso-latin-diacritics@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/NgDg...> 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/NgDg...> 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/10PiKG0grWcN2Q...> * 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/NgDg...> 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>