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

Proposed Agenda for Meeting #35
by Saewon Lee May 12, 2026

May 12, 2026

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #35 on Wednesday, 13 May 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #34 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB This week, the WG is expected to finalize discussions for PR29 and 18-19, review comments for 35-36, 11, 50, 14 (Rec #s according to the current Public Comment Review Tool, prior to updates), and conclude PR1 and move on to PR39. I know, it may be a tad ambitious but let’s see how we proceed! 😉 Please review the updated proposed language resulting from Meeting #34 in pp.35-37 on PRs2-3 here prior to the meeting: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1BTAlq9vGEVVe…> As an ongoing process during the review of Public Comment submissions, the WG discussions are updated in the Public Comment Review Tool here for your review: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1…> We appreciate your kind review of both materials each week. Much appreciated, 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

Post Call | Latin Script Diacritics PDP | Wednesday, 06 May 2026
by Devan Reed May 6, 2026

May 6, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 06 May 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AQA7PQ> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. 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. Kind regards, Devan Policy Team Supporting the GNSO

1 0

Action Items and Notes from Meeting #34 on 6 May 2026
by John Emery May 6, 2026

May 6, 2026

Dear LD PDP WG, Please see below the action items and notes from Meeting #34. [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> and the proposed draft after each WG Meeting and provide input, if any. Please review PR 1 and PR 39 * Staff and Leadership to prepare additional background information and examples on Edmon’s proposal * Alan to bring the query about fees to the Board and group to discuss whether to keep PR 18 and PR 19 in this context. [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #32 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQA7PQ> for previous and ongoing AI’s. Discussed PR 29 and Edmon’s proposal of a “High-Risk Scenario” if the application contains more than X LD TLDs it would trigger for a structured evaluation. Options on where this may be added outlined in the slide<https://icann-community.atlassian.net/wiki/x/AQA7PQ> * Discussion about what “high-risk” would be defined, then what kind of evaluation would be different in the review process and would need to be clearly defined. The WG has to put more thought in defining all these aspects * Unclear whether high-risk is the registry or end user. Support for more precisely the scenario. * Sarmad, there is a possibility that we are going to include a string that could be a blocked label of existing TLD. If that is the case then it goes against RZ-LGR. Two strings could be considered similar to each other through the regular process. Through the exception process, those could be delegated, still allowing the string to move forward. There is some inconsistency across strings and the manageability issue where end-users get multiple strings under multiple TLDs. He raised some aspects that need to be assessed * Blocked variants could not be added to the LD set as that is handled in the scope. * Applicants will have to provide information how they implement the whole set so that it is manageable for registrars and registrants. * End user discussion of possible issues and risks. * Steve outlined the high-risk of consumers, a high number of LD/ASCII delegated at once especially at the point of registration. Then there are challenges with operating sets as registrants. Assuming that end users will not understand that these exist or how they work for end-user confusion. A number of opportunities where confusion and weaponizing that confusion may take place. * Proposed language by Edmon postponed to next meeting. * Edmon wanted to address some of the red flags of conservatism. At the end of the day it needs to go to implementation and the Board needs to decide that, so that is what motivated this suggestion. There are uncertainties in this process and that is the motivation from ICANN org and that is the motivation for this proposal. 3. Review of LD PDP Initial Report Public Comment * Continued on the slides<https://icann-community.atlassian.net/wiki/x/AQA7PQ> for PR18 and PR19 ICANN Board adopted EPDP IDNs 7.4 and 7.5 and ICANN org submitted comments on the Board’s rationale and concerns. * Cost recovery principle is just for the application phase. For the operations phase, these are just registry fees. * Ariel gave context on the Board rationale for EPDP-IDNs Board did not adopt these until late as there is a challenge for registry fees. This is not within the usual policy topics for Board’s consideration. Registry fees are normally not in the purview of WG’s. Add in the uncertainty and here if the LD PDP proposes these then the Board may delay to discuss and deliberate. The Board adopted it for EPDP IDNs but does not set a precedent for registry fees. It is not necessary for the LD PDP to answer this. * Goal of PDP is to create an exceptions process to co-exist next to each other. Rec 18 would reduce the fees otherwise the registry would have to pay the fixed fee for each TLD, but also saying that those registries should pay less fees. * If this recommendation goes forward for price will be reduced that this has a high chance of being rejected by the Board as EPDP IDNs was not precedent setting * Alan from the Board reiterated that 7.4 and 7.5 for EPDP IDNs, they felt it was not the place of the policy team to set the fees. * Proposal to simply delete these recommendations? Also, to go to the Board through the liaison to see where the Board might sit then the WG can adjust the recommendations to increase the likelihood of Board approval * Alan has agreed to take this query to the Board to raise it to get feedback. * Steve tried to contextualize this recommendation. IDN variants where the community and Board wanted to encourage it which is not what the LD PDP is trying to do. This exception process will likely present challenges for the Board. Also, should not give recommendations to the Board that are challenging for them. Delay and complications come as a result. WG should try to develop recommendations that can be adoptable by the Board * A few individuals recommended dropping the recommendations. * PR 2 and PR 3 discussed slides<https://icann-community.atlassian.net/wiki/x/AQA7PQ> and the ALAC comment highlighted. Dropping this requirement would make it technically impossible to have the same entity principle. Agreement on the same entity principle, ALAC clarified that this should be flagged for consumer choice even if it cannot be implemented. ALAC is okay with the current way of doing this based on the charter and a technical necessity * Request to add to the rationale that it is a charter requirement for PR2 and PR3 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

Proposed Agenda for Meeting #34
by Saewon Lee May 4, 2026

May 4, 2026

Dear LD PDP WG, Happy May! I hope those of you who traveled to Manchester are back home safe and sound now. Please find below the proposed agenda for LD PDP WG Meeting #34 on Wednesday, 6 May 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #32 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB This week, the WG is expected to finalize discussions for PR29, review comments for 35-36, 18-19, 2-3, 11, 50, and 14 (Rec #s according to the current Public Comment Review Tool, prior to updates). Please review the updated proposed language resulting from Meeting #32 in pp.5-7 for IG8 and pp.18-19 for PR29 here prior to the meeting: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1BTAlq9vGEVVe…> As an ongoing process during the review of Public Comment submissions, the WG discussions are updated in the Public Comment Review Tool here for your review: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1…> We appreciate your kind review of both materials each week. Much appreciated, 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

Post Call | Latin Script Diacritics PDP | Wednesday, 22 April 2026
by Devan Reed April 22, 2026

April 22, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 22 April 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AQBHNw> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. 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. Kind regards, Devan Policy Team Supporting the GNSO

1 0

Outcomes, Action Items, and Notes from Meeting #32
by John Emery April 22, 2026

April 22, 2026

Dear LD PDP WG, Please find attached the outcomes, action items, and notes from meeting #32 on 22 April. REMINDER: there will be no meeting on 29 April due to the CP summit in Manchester, calendar invites have been canceled, but please make sure you don’t show up to an empty zoom room. [OUTCOMES] * Agreement with adjusted language for IG8 [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> and the proposed draft after each WG Meeting and provide input, if any. * Staff and leadership to update PR7/8 for “string” and “label” alignment and do so across all recommendations [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #31 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQBHNw> for consensus of PR6 and IG7. Discussed adjusted language for IG8 and there was alignment with the group of the new language. 3. Review of LD PDP Initial Report Public Comment * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQBHNw> deferring the resolution of the diacritic set to talk more broadly about the conservatism principle. Slide 9 went through the leadership/staff initial assessment of conservatism on the recommendations. * Discussion of the table and the purpose of overall conservatism. There is no objective number to say it is more/less conservative. This is a rough overview of a holistic view of the PDP for the group to see where we think we are. There is no hard requirement for conservatism, and it is subjective. * The group has been looking closely at each recommendation, and this is just a bird’s eye view of the recommendations. * PR7 likely moved to PR8 adjustments reviewed. Query about what “explanation” is required by the applicant. Sarmad clarified that these are verified at a level of “reasonableness” for EPDP IDNs. ICANN org panel evaluates on its own in the application and is not within the scope of this group. * It was shared that this standard of reasonableness is handled in IG8 * Sarmad noted that IG 8.1 might be useful to be slightly broader to also look at related scripts as well. It could be useful to say something like Latin and related scripts (Greek and others with reasonable similarity). WG did not think this needed a change. * Public Comment for PR7 reviewed for significant change required. 7.4 discussed the restriction for TLDs and there was wide agreement that it was in theory possible for an unlimited number of variants, it adds in restrictions. * PR12 PR13 discussed fees based on a cost recovery principle. Variants are a special case and ICANN was promoting these, which is why 4 were free. LD PDP goal is not to encourage people to get more LDs. It is the sole goal of creating an exception process to make it possible for applicants to have that TLD. * This is not for re-litigating the cost or fee structure, just going through the Public Comment on this topic. The scope of this PDP is narrow and not encouraging LD TLDs just creating an exception to make it possible. The conservatism principle is upheld by the recommendations unless someone wants to make them more conservative. * Concept of conservatism in the IETF context discussed. Idea of the name collision side that there are uncertainties here creating an exception that risks might arise. If there is a high-risk mechanism from NCAP that might solve part of the issue and increase conservatism. * Sarmad agreed that there is some unknown here that the process will allow potentially two strings to go into the RZ that would otherwise not be allowed because they would create user-confusion. Smaller step in the beginning and learn from it and know that it is okay then one can become more liberal. It is better to have in the RZ it is hard to delegate and take it out, that is not the right solution. That is where ICANN org is coming from in their Public Comment. * Question, by enforcing that these TLDs will resolve together, does it not solve the problem of confusion at its core? If the users confuse, it cannot be enacted; it does not meaningfully impact what type of user behavior or security behavior they would carry out. At what level are we trying to address user confusion? * Sarmad responded with an example. This is uncertain territory. Administratively tying the strings together (with the same registry and the same applicant and 2nd level the same registrant). But these strings introduce another variable that variants don’t do. That is that variant definition is consistent across all TLDs. In this case, the equivalence is applicant defined and that creates a level of inconsistency. We know that these strings will create user confusion and across different TLDs will be defined based on applicant request. That is an example of the unknowns on this topic of user confusion. * PR29 text updated and Sarmad proposed to add some conservatism and could be looked at in tandem with recommendations that talked about reasonableness for each variant to see if that creates sufficient conservatism. * The WG agreed that there should be no ceiling, but there could be an arbitrary ceiling to be more conservative. Proposal for anything after the first three would trigger a high-risk scenario 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

Outcomes, Action Items, and Notes Meeting #30
by John Emery April 22, 2026

April 22, 2026

Dear LD PDP WG, Please see the attached outcomes, action items, and notes from meeting #30 [OUTCOMES] * Wording from IG X to be incorporated into IG 7 [ACTION ITEMS] * Staff and Leadership to adjust language on IG8 [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #29 * Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQBENw> with PR6 and IG8 updated with redlines and strikethrough PR 6 on slide 7 * Wording from PR 6 in the past was turned into IG7 to make PR6 more concise, but still convey the group’s intention. * Discussion of withdrawal of applications corresponding to existing TLDs options outlined on slides<https://icann-community.atlassian.net/wiki/x/AQBENw> 9-10. The cases are a bit clearer in option 2 for IG X. WG coalesced around Option 2. * Should Option 2 be a separate IG or a combined into a single IG? * Policy Team comment: PR 6 was the original recommendation as it aligns with IDN EPDP and then the IG X was divided in this way to have an existing PR 6 and a separate IG 7 to align with ICANN org comment to align with EPDP IDNs while explaining the necessary steps. Framed this way as a best practice for drafting recommendations. Recommendation is capturing principle, but deeply into specifics that should be IG since it is so specific. * PR 6 basically just says you can get rid of strings or labels and the IGs explain in details how to withdraw a TLD under what circumstances this is possible. That’s why the separation is there * There is a chance that things are missed in the process and if it is in a recommendation then there is rigidity. The IRT then guides to ensure * Majority is indifferent, so wording from IG X will be incorporated into IG 7 * IG8 overview on slide<https://icann-community.atlassian.net/wiki/x/AQBENw> 11. * Query about an ASCII and to LDs if ASCII cannot go through then the set will get dissolved. Whether the two LD TLDs can go together without a set or whether just one LD would be processed. * Answer: since the rule is that one cannot switch between the exceptions process and the standard process. One would have to choose a single one and then would be able to continue. * Staff and leadership to improve the wording of IG8 based on the query * Looking at scope and characters to stay with diacritics as decomposable or expanding characters with a limit as outlined on slide<https://icann-community.atlassian.net/wiki/x/AQBENw> 12. * Two Options discussed: questions raised by Council liaison what is the clear, objective, and machine-testable baseline. Is the baseline sufficient for WG to achieve its goals? Would this be an expansion of scope? * Christian: added analogy ensuring that the WG can set a floor and a ceiling. Floor is common application and ceiling is outliers. * Floor would be the unicode decomposable, and the Tapani proposal would be a ceiling and should not go too far for outliers. The definition could be finite, predictable, and could be changed if Unicode changes * Process problem rather than a technical problem of the code points. The PDP WG cannot enlarge its remit and scope. The WG has provided a definition all along and the Public Comment did not raise this. There was a very real request from the community resulting in a narrowly scoped PDP. Option 2 can accommodate more, but there is a lot of anxiety about when the work will finish. Is the group redefining its own scope? But having worked all this time on the unicode table, it might be difficult to change and redefine that. It was not a push from the community, and it will make it longer. * ICANN org points outlined on slide<https://icann-community.atlassian.net/wiki/x/AQBENw> 14 and Sarmad contextualized his points. Explained the development of RZ-LGR and its design. Inclusion principle and conservatism principle works generally overall. Inclusion principle discusses two ways of managing characters: start with everything and exclude, or start with an empty set and include only necessary characters. Each script should be an empty set and community decides the characters needed for RZ-LGR * Second principle of variants. RZ-LGR maximize variant sets and block them. Wherever there is a chance of confusion, that confusion should be addressed and then they should be allowed and blocked to avoid confusion. RZ-LGR wants to maximize blocked variants. As an exceptions process some of those could be allocatable, which would be minimized (only those absolutely necessary). * Those are the principles. Here the WG is creating an exceptions process for what is already happening in the RZ-LGR. This PDP is an extension of the allocatable variants. Allocatable variants are an exception. This an exception to that exception, so this should be extremely conservative. Motivation is the underlying SSR challenges. * Sarmad discussed the conservatism principle and this is the first time doing it at TLD level as it has implications with millions of second-level implications. Once the community gains experience it can be made more liberal. Using the same argumentation in designing RZ-LGR, considering allowed diacritics a third option: design principle of inclusion starting with an empty set to add diacritics which are needed. * At a policy level the WG can create policy to guide how that set should be developed then a separate community WG could be done to document why each diacritic should be included * Michael asked: Do not deal with the question in this PDP, just make the rules for some other WG or generation panel that would then be responsible for defining which characters can be used in this policy? * Sarmad: Yes, RZ-LGR is a process that can evolve over time. If you make it part of the policy, it gets stuck unless there is a mechanism to spin it off into a community WG to develop this over time to not constantly update the policy. * Response from WG was skeptical of the third option proposed by Sarmad. There needs to be a criteria and support for Option 2 from Tapani seems quite workable. * Sarmad clarified through RZ determining what TLD can go into the root zone. In certain cases two strings going into the root zone, they must be managed by the same registry operator. From that perspective, the LD TLD is trying to do the same thing. Which additional strings are not allowed could still go to the root zone. LD and RZ-LGR are parallel and similar to allow more strings into the root zone. * Overall, the WG was convening on Option 2 and did not agree with the comments from Sarmad. * Majority of group members in favor of option 2 * Sarmad: unicode experts consulted on option 2, and parsing letter names is not a predictable process as unicode does not design names “with” that anything follows has to be a diacritic, it could actually be other items that may or may not be a diacritic. Unicode expert in the context of option 2 there is an implication for the unicode. * Machine readability is not 100% required as the list created does not necessarily have to be generated over and over again. The list here could be a fixed list and a rule on what to do if new characters get introduced. * Sarmad shared the Unicode expert opinion ““Not a good idea to data mine the names list for this. The way decomposition is made on the names is not regular, the concept of diacritics may also be fuzzy. You may have a ‘with’ but the following element is not a diacritic (example 00D8: LATIN CAPITAL LETTER O WITH STROKE), the description of the diacritics may also not be totally regular, thinking of the block 1E00-1EFF. The best way is to use UnicodeData.txt, Scripts.txt (to determine Latin), and then look into UnicodeData.txt to see which Latin characters decompose and get the exact decomposition.” * Sarmad: his proposal would be a smaller set likely. But the motivation is to create a deliberate set to only include those things that are actually needed, and it may lead to the same set, but the inclusion method was the proposal not the smaller set. 3. Review of LD PDP Initial Report Public Comment 4. Next Steps 5. 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>

2 1

Proposed Agenda for Meeting #32
by Saewon Lee April 21, 2026

April 21, 2026

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #32 on Wednesday, 22 April 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #31 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB This week, the WG is expected to confirm language for IG8, review comments for PR7, PRs 12-13, PRs 18-19 (Rec #s according to the current Public Comment Review Tool, prior to updates), as well as PRs 2-3, and IG11 and PR50. Please review the updated proposed language resulting from Meeting #31 in pp.5-6 and p.30 for IG8 here prior to the meeting: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1BTAlq9vGEVVe…> As an ongoing process during the review of Public Comment submissions, the WG discussions are updated in the Public Comment Review Tool here for your review: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1…> We appreciate your kind review of both materials each week. Much appreciated, 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

Post Call | Latin Script Diacritics PDP | Wednesday, 15 April 2026
by Devan Reed April 15, 2026

April 15, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 15 April 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/fQBANw> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. 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. Kind regards, Devan Policy Team Supporting the GNSO

1 0

Outcomes, Action Items, and Notes Meeting #31
by John Emery April 15, 2026

April 15, 2026

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] 1. Welcome and SOI Updates 2. Recap of Meeting #29 a. Key Outcomes and Action Items * Went through the slides<https://icann-community.atlassian.net/wiki/x/fQBANw> 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<https://icann-community.atlassian.net/wiki/x/fQBANw> * 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<https://icann-community.atlassian.net/wiki/x/fQBANw> 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<https://icann-community.atlassian.net/wiki/x/fQBANw> 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) www.icann.org<http://www.icann.org>

1 0