Dear LD PDP WG,

Please see attached below the outcomes, action items, and notes from Meeting #31 on 15 April 2026.

[OUTCOMES]

[ACTION ITEMS]

Staff and Leadership to update IG 8.6 to include “negative” will involved the dissolution of the set
WG to think through the meaning of conservatism and to brainstorm potential ways to increase conservatism to address ICANN org’s comment.

[NOTES]

Welcome and SOI Updates
Recap of Meeting #29

a. Key Outcomes and Action Items

Went through the slides to discuss updated language from the previous meeting.
Confirmed language of PR6 and its division into IG7
IG 7 and IG 8 adjustments outlined based on last week’s discussions in the slides
Discussion for IG 8 of possible scenarios the timing with the evaluation would not be dealt with in our PDP.
Ariel explained the process of evaluation timing will occur in stages for string evaluation. At the end, there will be an outcome report with some processes kicking in. The WG should not be too specific as this is community policy from SubPro PDP.
8.6 causes dissolution of the set for the evaluation of an outcome of an ASCII by causing the dissolution of the set.

3. Review of LD PDP Initial Report Public Comment

Took holistic view of ICANN org comment though slides for comments received for PR 1. Explanation of substantive vs. non-substantive public comment
ICANN org substantive comment for PR 1 overview given with consideration for what additional security and stability issues may arise from the introduction of these sets. Conservatism principle is primary across all recommendations and if there are additional measures needed to prevent proliferation of exceptions
A number of substantive comments outlined on PR 1 about scope
Read through adjustments to PR 7, PR 12-13, PR 18-19 in relation to PR 1 from ICANN org
New suggestion by Claude based on the inclusion principle and conservatism principle outline on slide 20. Exclusion was when a glyph was not related to an ASCII letter, the glyph is automatically excluded from the set
Discussion of comment on PR 1 from ICANN org looking at scope for what characters are reasonably supposed to be in the scope of this project. This is an RZERC question that this group is not equipped to answer
Sarmad: added context to the comment from ICANN org. This PDP will eventually allow for some strings to go into the root zone. ASCII and diacritic into the RZ this process for the applicant would pull those strings into a single application and set could still go into the RZ. Another case with 3 strings through an exceptions process would not have made it to the RZ. Normal policy any strings similar do not go into the root zone. Variants are well-defined and allowed, this is extending the process for non-variant strings that can go to the root zone.
Sarmad summarized that variants is a well-defined process and predictable through the RZ-LGR. These sets are defined by the applicant, which defines the root zone. It is an exception process allowing some strings to go into the RZ-LGR which would not have made it through the regular process.
Discussion based on the comment with a belief that the WG is conservative and the scope of the characters should be the element addressed.
Sarmad: This PDP is an exception process to allow for some TLDs to move forward. Through this process any ASCII character all the discretized versions are getting an allocatable disposition and this is different than the RZ-LGR was designed. What is presented from a character level disposition. At the string level you can go into the root zone. Theoretically more strings at the character level and at the string level would introduce more into the root zone, this is a less conservative solution for the root zone.
Query about RZ-LGR e and e acute or any other LD are not defined as blocked variants? They are simply not variants? There are a few diacritics that are variants. These are out of our scope. The RZ-LGR allow all the characters to be used in TLDs, it is whether we are allowing similar TLDs to be operated by the same registry.
Michael outlined two opposing opinions. WG and ICANN org to find a compromise that works. To be able to uphold the conservatism principle 1) restrict characters (group is mostly opposed to that along with other commenters) this is not a good way to achieve this and don’t want to give preference to language group. 2) That would allow the set of diacritics or second option from Tapani and that would be to change some of the recommendation that will make them more conservative.
Sarmad: Similar strings would be allowed in the RZ to exist together. Conservatism would ask to reduce it or make it smaller. There are other ways to eventually reduce the strings in the policy. This is not an isolated request or suggestion. In the variant discussions and policy. RZ-LGR by design minimizes allocatable variants.
Sarmad clarified with example of through the regular policy process two strings considered similar both strings cannot proceed to the RZ, only one can proceed after contention resolution. If those strings through this process to allow both to go the RZ.
The exception for the number of possibilities is getting too big. Sarmad is saying this is aligned with the charter and the PDP. The org comment is asking if this can be done more conservatively.
Raising the issue for SSR of the Internet, but the question is a dilemma of what is the definition of conservatism today, and how would that change over the future.

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)