Hello LD PDP WG, Please see attached. Outcomes, Action Items, and Notes from Meeting #20<https://icann-community.atlassian.net/wiki/x/HADgGg> 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<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgduN...> 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<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/450887708...> 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<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/450887708...> 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<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgduN...> * 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>