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

Outcomes, Action Items, and Notes for Meeting #35
by John Emery May 13, 2026

May 13, 2026

Dear LD PDP WG, Please find attached the outcomes, action items, and notes from meeting #35. REMINDER the remaining meetings for May will begin 15mins earlier at 13:00 UTC [OUTCOMES] * Meeting moved from 13:15 to 13:00 UTC for the remainder of May meetings * The group majority was in favor of retaining PR18 and PR19 concerning fees. [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 propose language from Amadeau’s proposal to not have ASCII and LD gTLDs to not coexist independently. [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #34 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/PAA7PQ> for action items * Proposal to move the meeting from 13:15 UTC to 13:00 UTC. 3. Review of LD PDP Initial Report Public Comment * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/PAA7PQ> to discuss PR18-19 for the registry fees and Alan’s query to the Board * Board input was divided with some believing that the recommendations are aligned with EPDP-IDNs with others unsure of financial impact and one objection given that EPDP-IDNs should not set a precedent, then it is a precedent * Discussed paths forward considering Board’s comment. Some WG members advocated for keeping PR18-19. This would help the adoption of this exception, but the Chair noted that this is not the mandate for the WG. Charter is to make it possible not to promote it. * Query about possible financial impact to make an informed decision. It is a vague recommendation because pricing is not policy that is ICANN org’s decision * Steve Chan added some input on the pricing aspect. Ambiguity of the impact as it is unknown is part of the rationale for the Board only adopting the IDNs recommendation for unknown impact and this is typically not something that policy development recommends. * Ariel Liang, agreed with the ambiguity as to why the Board had the caveat of EPDP-IDNs, there will be more information with the next round. For this LD PDP recommendations there are some differences. The financial analysis this more for ICANN org to do later when the recommendations are adopted by GNSO Council. Then org will provide an analysis. * Majority of WG was in favor of retaining PR18 and PR19 * Steve Chan stressed that at the Council level there is a push for Board Readiness and if the WG is aware at the Board level it should be considered. If there is Board resistance it sets up a lengthy process and extra work throughout the process. * Discussion of fees and the idea that there is uncertainty and the probable number of applications for LD PDP vs EPDP-IDNs * PR29 suggestion from Edmon for a high-risk scenario in the slides<https://icann-community.atlassian.net/wiki/x/PAA7PQ> and outlined the options * Reviewed the overall conservatism scale of the WG recommendations * Looking at high-risk scenarios through the slides<https://icann-community.atlassian.net/wiki/x/PAA7PQ>. * PR 7 addition discussed for a justification for application submission * The high-risk scenarios discussed by the WG, likely there will not be user confusion as that the SSE Panel would likely not allow it to move forward * Risk of confusion could increase so the SSE should take into consideration the users so as a principle other diacritics should not be allowed from other registries * Suggestion that even though it is likely that the SSE panel would find them visually confusingly similar. There should be a recommendation to take this into account for the next AGB * Sarmad: The cafe and cäfe example scenario is theoretically possible and it happens precisely because arbitrarily cafe and café are put together. It depends on the SSE panel, and we cannot determine the panel’s outcome. * WG disagreed with Sarmad’s concern on the theoretical possibility * Two questions to resolve: do we need to introduce a special high-risk scenario into our recommendations or add some additional precaution on slide 18 for 7.5 for PR7 to avoid potential issues. * Sarmad’s suggestion is to not specifically require any criteria here but give the implementation team the possibility to create some criteria that would take care of potential end user confusion here. * High-Risk scenario from Edmon perhaps not needed given the other ways in which conservatism is established with fees and PR7. * Suggestion to have a recommendation requiring the SSE panel to not have any ASCII and LD TLDs to move forward independently, only as a LD set. String sim check has to prohibit this. * WG seemed intrigued by Option 3 for Amadeau’s proposal and the LT and staff will come up with language for it. 4. Next Steps 5. 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

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

May 13, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 13 May 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/PAA7PQ> (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

Feedback from the board liaison
by Alan Barrett May 13, 2026

May 13, 2026

First, please accept my apologies for today's meeting, which I will miss. I raised the fee-related questions informally in a Board mailing list. Opinion was divided, with some thinking that the LDPDP recommendations were well enough aligned with the IDN EPDP recommendations that it would not be a problem, and with others supporting ICANN Org's comments that we dont know what the financial impact would be. One member specifically called out the idea that approval of the IDN EPDP fee recommendations was not supposed to set a precedent, yet the LD PDP seems to be using that as a precedent, and this seems inconsistent. Regards, Alan Barrett

3 2

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