March 2026 - Gnso-latin-diacritics

Diacritics definition
by Tapani Tarvainen April 1, 2026

April 1, 2026

Dear all, Looking at the initial report recommendation 1, it gives the chosen definition of diacritics as a fact, without explaining or justifying it in any way. It should, so that if someone wonders why ø or ŋ are treated differently they should be able to look at the report and find an eplanation. I also note the ISOC Norway comment that wants a technical reason for the exclusion of characters used in Norwegian and Sami. I tried to think of how to explain it. As I recall, the argument was that the charter specifies diacritics only and Unicode defines them that way and if we want to include something else we'd have to go back to the council and there's no time for that. But does Unicode really define them that way? I went to the source to see what Unicode actually says about the matter, and importantly also what it does *not* say. Not an easy task - there's *a lot* of stuff in there. But try as I might, I could not find a general definition of "diacritic" anywhere. Perhaps I've missed it - if so, feel free to point it out. There's lots of talk about combining diacritic marks and decomposable diacritics - but no claim that those are the only kind of diacritics. It's simply that for Unicode's purposes the non-decomposable diacritics don't need any special treatment, so there's no need to even define them. For Unicode, decomposable diacritics are special because they need special rules for canonicalization. But for our purposes that doesn't matter. In effect we took the Unicode table of decomposable diacritics and decided to treat it as if those were the only diacritics. This decision was not given to us by the charter nor by Unicode, it was our choice. I see no good reason not to allow all Unicode characters described in Latin-1 Supplement or any of the Latin Extended tables as "LATIN SMALL LETTER <x> WITH <y>" where <x> is an ASCII letter and <y> is any glyph that modifies the base letter (which is the general meaning of "diacritic mark") in a way that makes them confusable, regardless of the existence of a decomposed canonical equivalent, as long as they are in the RZ-LGR. My favorite example here is of course "latin small letter with stroke", ø. If we conclude that there is a good reason for excluding such non-decomposable diacritical characters, we should spell it out. I don't see any good *technical* reason to exclude even characters like ð, þ, ŋ, æ etc, but they are not diacritical and thus outside of the charter, and in some cases might require aditional considerations, so I guess we'd have to back to the council for those, or wait for another PDP ("Extended Latin Characters PDP" perhaps?). (Side note: during a coffee break discussion in Mumbai someone said old issues shouldn't be relitigated *unless* there're new facts or new viewpoints to consider. Here I think there are.) -- Tapani Tarvainen

8 23

Proposed Agenda for Meeting #29
by Saewon Lee March 30, 2026

March 30, 2026

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #29 on Wednesday, 1 April 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #28 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB As shared last week, the WG is expected to review the following comments/topics in order through Agenda Item #2: PR6, IG8, definition of diacritics (Mark vs. Tapani), IG11, PR50. If time for Agenda Item #3, we will continue with reviewing the comments received in order through the Public Comment Review Tool starting with PR1. Please plan to review them accordingly in advance, including Topic 3 (PRs 3-14) in pp.32-44 which is the portion related to the application process. As an ongoing process during the review of Public Comment submissions, please find below the WG discussions updated in the Public Comment Review Tool and the draft updated language that resulted from the WG’s discussions below: * Updated Public Comment Review Tool per WG’s discussions: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… * Draft with updated language from WG’s discussions: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… We would 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

Request for Review of Recommendations and Rationales
by Saewon Lee March 26, 2026

March 26, 2026

Dear LD PDP WG, As we review the public comments each week, the Leadership Team and Staff kindly ask that everyone take a moment to revisit the recommendations and their underlying rationales in advance of our weekly meeting to refresh our recollection. (See Initial Report here: https://gnso.icann.org/sites/default/files/policy/2026/draft/initial-report…) We recognize that some time has passed since the Initial Report was developed, and it is natural for details to become less clear. Hopefully, revisiting the report will help ensure we remain aligned with what was previously discussed and agreed upon. As noted in the disclaimer during ICANN85, our intention is not to revisit or reopen matters that have already been thoroughly discussed and agreed upon, unless genuinely new information or perspectives emerge. Where topics have already been addressed, it is important that we focus on strengthening the language and rationale, which may clarify how comments have been considered and why the WG may have reached its conclusions. For next week, the WG is expected to review the following comments/topics in order: PR6, IG8, definition of diacritics (Mark vs. Tapani), IG11, PR50. If time, we will continue with reviewing the comments received in order through the Public Comment Review Tool starting with PR1, PR2, PR3. Please plan to review them accordingly in advance, including Topic 3 (PRs 3-14) in pp.32-44 which is the portion related to the application process. 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, 25 March 2026
by Julie Bisland March 25, 2026

March 25, 2026

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

1 0

Outcomes, Action Items, and Notes from LD PDP WG Meeting #28
by John Emery March 25, 2026

March 25, 2026

Dear LD PDP WG, Please see the attached outcomes, action items, and notes from the WG meeting on 25 March 2026 [OUTCOMES] * PR 6 It should be possible to remove the ASCII TLD if only a single diacritic TLD remains. Two cases with one with multiple TLDs remaining and the sole TLDs remaining * IG 8: Once you start with the exceptions process you cannot switch to the standard process you have no ability to drop the ASCII, just like in the variant case you have no ability to drop the primary string. [ACTION ITEMS] * PR 6 enacted a suggestion to make Latin Diacritic string(s) with the possibility of plural. Then to delineate the two parts of PR 6 with multiple diacritics vs a single diacritic and ASCII. * IG 8 Leadership and Staff to come up with examples to seek to clarify the definition of a set and what can be dropped when the exceptions process is chosen. * WG to think about the suggestion from Tapani and the Mark list and consider keeping with Unicode to continue discussion next week. * WG to focus on reviewing this document to check the draft language from ICANN85 and provide input. https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… [NOTES] 1. Welcome and SOI Updates 2. Recap of ICANN85 a. Key Outcomes and Action Items * Went through slides<https://icann-community.atlassian.net/wiki/x/AQBANw> reviewing what happened at ICANN85 through the public comment review tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…>. Public Comment summary report <https://itp.cdn.icann.org/en/files/generic-names-supporting-organization-co…> has also been published. * Outstanding action item to revisit recommendations 6, 8, and 50 after reviewing language 3. Review of LD PDP Initial Report Public Comment * Went through slide<https://icann-community.atlassian.net/wiki/x/AQBANw> 7 on PR 6 reviewing ICANN org public comment for discussion * Discussion of application where it is not possible to add anything for the window closed, suggestion to say that future rounds can be stated explicitly in PR 6 rationale * Do we only want to allow the removal of diacritic labels, then the ASCII also must exist? What if the second to last label would be removed? Should it be possible to dissolve the set and allow a single remaining label with an ASCII or LD TLD or does it have to be the ASCII * Here there is an artificial bundle unlike IDNs that * Sarmad: it is two different cases, one with multiple diacritic versions and an ASCII. ASCII must exist and may not be removed, but some diacritic versions could be. Second recommendation is that if there is a situation where one is left with only a single ASCII and single diacritic then either one could potentially be removed. This is two parts of the recommendations or two different recommendations. * Suggestion to have two parts of PR6 * Org comment the applicant can withdraw if it is an ASCII LD set, this is a non-substantive comment to help future applicants to understand what they can/cannot do in applying for a string * IG 8: ASCII/diacritic string vs. label? Should they be the same language? String is used when referring to primary and label refers to variant from IDNs. When we get to application implementation it is just called a string. Strings is generally used * ICANN org comment reviewed on slide<https://icann-community.atlassian.net/wiki/x/AQBANw> 10: context from IDN EPDP there is one principle that the primary is the key to hold the integrity of the set. If primary does not pass evaluation then the entire set will fail. New gTLD for the ASCII/LD set it is not very clear if the ASCII fails evaluation, what happens next? One diacritic could still go ahead with the evaluation phase? * Related to other comments in terms of objection if ASCII is objected to and objector prevails. IDN EPDP does have a recommendation on that, but there is not an equivalent recommendation for LD PDP * What happens if ASCII/LD for remainders of the set if one cannot go forward? * Discussion: it is an unlikely case, but should have a rule for corner cases. Should have a decision if that case exists. * Sarmad: If the primary cannot move forward, then the strings cannot. That somewhat conflicts with PR 6 whether they are a set or not. This inconsistency is coming in this case because in the variant case, the variant can never move forward without the primary. In some cases we are saying here the LD can move forward without the ASCII. Variants depend on primary and our LD string does not, it is independent and only as a requirement. * Solution: be consistent with PR 6 if a diacritic is invalid it can be dropped, but if ASCII is invalid then the set would have to be dissolved and only a single LD could move forward * Sarmad: it may be unlikely, but not impossible, so it needs to be discussed. * IG 8: suggestion would be to be fully consistent with IDN if an LD is invalid then it can be dropped if an ASCII is invalid, then the whole set should be dropped. * Consensus: in case a diacritic gTLD 8.5 accounts for the case when an LD TLD fails the rest can continue. * The open issue is the case if the ASCII fails the evaluation, then what should we do? * The whole application should fail if ASCII fails in line with variant case and add 8.6 * Refer back to PR 5 treating the bundling. In the case that when we apply as a set, it is bundled and it cannot be unbundled in the middle. This is a little different to the evaluation, but was agreed upon. Based on this LD exception process, unbundling the set either of the strings would be allowed to move forward in PR 5. * Going back to the point that was raised for IG 8 if there is agreement that the LD set should be like EPDP IDNs then there should be a corresponding recommendation, which would be 8.6 * PR 5 discussed on slide<https://icann-community.atlassian.net/wiki/x/AQBANw> 11. Cannot switch between standard or exception process. Does that mean once you start with the exception process, or does this also cover when there is only a single TLD process, but it could be viewed as a set with only one element. * Sarmad: When you have one LD string left along with the ASCII, the group then said that either one could be dropped. If very strictly using the set formation and not independent string formation, once you have chosen this, you must stay on this path. It could not be that you could drop ASCII or LD, they could only drop LD or withdraw ASCII, that would make it more consistent with current discussion * Should it be possible to drop an ASCII string and just proceed with a single LD string? Solution 1) As long as a set exists you have to have one ASCII. 2) Should it be possible to dissolve the set and only have the LD TLD and move forward? Or should that be disallowed? Once you start the exceptions process you must keep the ASCII. * IG 8 Consensus: Once you start with the exceptions process you cannot switch to the standard process you have no ability to drop the ASCII, just like in the variant case you have no ability to drop the primary string. * Discussion IG 8: if the ASCII fails evaluation then the entire set fails * IG 8: Once you start with the exceptions process you cannot switch to the standard process you have no ability to drop the ASCII, just like in the variant case you have no ability to drop the primary string. * Discussion of Diacritics via Unicode from list. Non decomposable is out of scope as we have defined it or as it is in the Charter. Is it flexible? This was from the WG decision. * Slide 28 outlined the list discussion for the Unicode vs. Latin small letter with diacritic * Problem is keeping it testable and bounded. How do we test those boundaries? Whatever is decided moving forward it needs to be testable. * Mark came up with additional characters using the theory of Latin small letter with. It would add some unexpected characters, but there is a clean implementation path. Latin small letter with is viable. This does not exactly fit the model of composition of characters. Here there is an arbitrary subset named latin small letter * Suggestion: There's a bug in your code Mark. You should only allow "LATIN SMALL LETTER [A-Z] WITH", exclude non-ASCII letters like EZH * Sarmad: normally when processing strings we are using unicode data files and general category properties for characters. It is an interesting idea to parse the name of the character with a string as suggesting. Wondering whether the existing property structure of unicode could be used in this case from a programmatic point of view. That could be parsed, but generally that is not the practice * Mark: F with the hook would not be an issue as that is already a variant and would be out of scope of our PDP. 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

Preparation for Scope Discussion: Scoping Exercise Doc. By Mark Datysgeld
by Saewon Lee March 23, 2026

March 23, 2026

Dear LD PDP WG, As we prepare for our upcoming discussions on the scope of our work (PR1 and PR39), please find attached a Scoping Exercise document drafted by Mark Datysgeld, Vice-Chair of LD PDP, based on his personal assessment of the subject and the WG's agreement. We hope that this document, along with the points raised by Tapani, will serve as a useful foundation for our discussions – particularly as we consider the comments received on PR1 and reflect on the scope of our work. The summary of Mark's points is as follows: - Changing the RZ-LGR has been explicitly outside of the scope of the PDP from its inception. - The WG has consensus that broader issues are intentionally left to future PDPs so this one can remain narrower, as was very directly and precisely asked of us by the GNSO community. - We did not decline the broader model because we failed to notice it. We declined it because adopting it with due responsibility would have required a materially different Charter, a much longer horizon, and a much larger policy design exercise than was allowed and asked of us. *In addition, a list of non-diacritic or non-decomposable cases and why they don't comply or make sense within our PDPs is included. Kindly review both Mark's and Tapani's inputs in advance, as they will be important for our discussion on character choices and definitions during the meeting on Wednesday. Kind regards, Saewon On 3/23/26, 7:21 PM, "Michael Bauland via Gnso-latin-diacritics" <gnso-latin-diacritics(a)icann.org <mailto:gnso-latin-diacritics@icann.org> <mailto:gnso-latin-diacritics@icann.org <mailto:gnso-latin-diacritics@icann.org>> <mailto:gnso-latin-diacritics@icann.org <mailto:gnso-latin-diacritics@icann.org> <mailto:gnso-latin-diacritics@icann.org <mailto:gnso-latin-diacritics@icann.org>>>> wrote: Hi Tapani, thank you very much for the additional analysis and for providing the info a few days before our next call. So everybody has the chance to look at this and we can discuss it during Wednesday's call. I would like everybody to read and think about Tapani's arguments. If understood this correctly, it mainly is about whether diacritics are only those characters, which are decomposable into an ASCII character and one or more diacritics (i.e., Combining Diacritical Marks https://urldefense.com/v3/__https://www.unicode.org/charts/nameslist/n_0300… <https://urldefense.com/v3/__https://www.unicode.org/charts/nameslist/n_0300…> <https://urldefense.com/v3/__https://www.unicode.org/charts/nameslist/n_0300…> <https://urldefense.com/v3/__https://www.unicode.org/charts/nameslist/n_0300…> <https://urldefense.com/v3/__https://www.unicode.org/charts/nameslist/n_0300…> <https://urldefense.com/v3/__https://www.unicode.org/charts/nameslist/n_0300…> <https://urldefense.com/v3/__https://www.unicode.org/charts/nameslist/n_0300…> <https://urldefense.com/v3/__https://www.unicode.org/charts/nameslist/n_0300…>)?__;!!PtGJab4!67jJLzYSS-eOjjI-7xFxB66ApyuWTl7w34kHmAIWtYmHAN9JevxGmkO7bcmziMFYsV2xGvE_K8qWqZt81isPo6gJ3nuUsrfSmA$ [unicode[.]org] Or whether characters that are not decomposable, but still have a name like: "LATIN SMALL LETTER O WITH STROKE" which denotes a composition of ASCII and something else should be considered as diacritics? Talk you to you all on Wednesday, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland(a)knipp.de <mailto:Michael.Bauland@knipp.de> <mailto:Michael.Bauland@knipp.de <mailto:Michael.Bauland@knipp.de>> <mailto:Michael.Bauland@knipp.de <mailto:Michael.Bauland@knipp.de> <mailto:Michael.Bauland@knipp.de <mailto:Michael.Bauland@knipp.de>>> Software-Entwicklung E-Mail: Michael.Bauland(a)knipp.de <mailto:Michael.Bauland@knipp.de> <mailto:Michael.Bauland@knipp.de <mailto:Michael.Bauland@knipp.de>> <mailto:Michael.Bauland@knipp.de <mailto:Michael.Bauland@knipp.de> <mailto:Michael.Bauland@knipp.de <mailto:Michael.Bauland@knipp.de>>> Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp Zertifiziert nach DIN ISO/IEC 27001:2017 _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics(a)icann.org <mailto:gnso-latin-diacritics@icann.org> <mailto:gnso-latin-diacritics@icann.org <mailto:gnso-latin-diacritics@icann.org>> <mailto:gnso-latin-diacritics@icann.org <mailto:gnso-latin-diacritics@icann.org> <mailto:gnso-latin-diacritics@icann.org <mailto:gnso-latin-diacritics@icann.org>>> To unsubscribe send an email to gnso-latin-diacritics-leave(a)icann.org <mailto:gnso-latin-diacritics-leave@icann.org> <mailto:gnso-latin-diacritics-leave@icann.org <mailto:gnso-latin-diacritics-leave@icann.org>> <mailto:gnso-latin-diacritics-leave@icann.org <mailto:gnso-latin-diacritics-leave@icann.org> <mailto:gnso-latin-diacritics-leave@icann.org <mailto:gnso-latin-diacritics-leave@icann.org>>>

1 0

Proposed Agenda for Meeting #28
by Saewon Lee March 23, 2026

March 23, 2026

Dear LD PDP WG, I hope that everyone who traveled to Mumbai for ICANN85 has returned home safely. Please find below the proposed agenda for LD PDP WG Meeting #28 on Wednesday, 25 March 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of ICANN85 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB As we continue with the review of Public Comment submissions, please find below the WG discussions updated in the Public Comment Review Tool and the draft updated language that resulted from the WG’s discussions below: * Updated Public Comment Review Tool per WG’s discussions: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… * Draft with updated language from WG’s discussions: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… We would appreciate your kind review of both materials. Additionally, as Michael suggested, we would appreciate your thoughts and input on the definition of diacritics as it relates to the scope of our work (PR1 and PR39). 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

Outcomes, Action Items, and Notes LD PDP at ICANN85
by John Emery March 7, 2026

March 7, 2026

Dear LD PDP WG, Please find the attached outcomes, action items, and notes from the LD PDP discussions at ICANN85. [OUTCOMES] * WG agreed with Inconsistencies 1 and 3 to be updated by staff * Majority in favor of recommendation 7 to utilize the EPDP-IDNs of 3.5.2 Explanation of how the primary and variant labels are considered the same” * Updated Public Comment Review Tool [ACTION ITEMS] * Staff to update Public Comment Review tool to be updated by staff and then a draft will be circulated to the WG. * Follow up with Ariel on IG 11 query and staff to add a word or “general” to intent. * Staff to Update language based on consensus discussed in WG for each recommendation * WG to postpone and revisit discussion of Preliminary Recommendation 50 * WG to follow up with Ariel on PR 6 if ICANN org comment becomes a substantive comment given the requirement in PR 1 and PR 6 * All WG members to review the Public Comment Review tool with special emphasis on PR 1 and PR 39: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [NOTES] 1. Welcome and SOI Updates * Seb updated his SOI from GoDaddy to Unstoppable Domains and noted he is a part of this PDP. 2. Overview of LD PDP Initial Report Public Comment * Saewon went through the slides <https://icann-community.atlassian.net/wiki/x/AQANKQ> with an overview of the Public Comment. * Shared the Public Comment Review Tool: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… * Public Comment summary report will be available here shortly: https://www.icann.org/en/public-comment/proceeding/latin-script-diacritics-… * PR 1 and PR 39 may need to be addressed as it concerns the scope of work. * Key Principles were mentioned during ICANN85 sessions reviewing of the Public comment submissions was done through the slides, but going forward the tool will be the primary source * GOAL: not to revisit or reset agreements unless it is crucial to keep the key principles in mind as on slides<https://icann-community.atlassian.net/wiki/x/AQANKQ> 9 * Mark D. emphasized the openness of the PDP to reach consensus. Managed to get consensus pretty well constrained and that is a win. Some public comments were substantive, and will not rehash, but reassert the position. * Mark: There is a substantial impact from ICANN org and there was a seat here during the PDP. ICANN org was able to participate thoroughly. ICANN org is just another person giving feedback to the PDP and it will be addressed in the same way throughout the process. * Welcomed Christian Dawson as the new liaison for the GNSO Council given his substantial expertise in these areas * ICANN org input could be slightly different given the core issues and some of those discussions may need to be had with the Board as well through the liaison 3. Start Review of LD PDP Initial Report Public Comment * Slides<https://icann-community.atlassian.net/wiki/x/AQANKQ> 10-11 discussed the issue of consistency for the style of writing between IDNs and LD to be precise unless there is a reason to differ from the original language. * Floor opened up for discussion for the consistency issue from org. Michael asked if it is necessarily the same. If the intention and meaning is the same even if there are small differences that are required to make it the same * Consistency Issue 1 is straightforward and can be done. Consistency issue 3 raised in terms of PR 35 and 36 differed largely from EPDP-IDNs so here there should be a language different from and which part is different within the recommendation language * Sarmad added in doing implementation analysis it is helpful to understand if the recommendation is the same as or consistent with IDN-EPDP, then you can easily look at analysis for IDNs to inherit it. If it is different, it requires an independent analysis with some overlap and some difference, look how it was analyzed in IDNs. * Inconsistencies in 1 and 3 are quite clear. * Flagged the issue that there is a lot of dependence on EPDP-IDNs, consistent with is that it is dependence heavy. What happens if there is EPDP changes, we might want to consider how that might be impacted * Public Comment Review tool to be updated by staff and then a draft will be circulated to the WG * Inconsistency 2 needs to be gone through one-by-one on how to label each from the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> * Recommendation 7: ICANN org noted that the LD PDP has differed from the original language * Actual words used should have the same meaning. This is an exceptions process to prevent user confusion, then it is reasonable to justify why you want to handle these TLDs jointly, this is not too much as a requirement * The recommendations from this PDP and IDNs should be consistent. If this PDP has used some of the language then it should be consistent * Sarmad: The motivation for EPDP IDN’s for rec 7 was the general aim was to minimize the number of variants delegated and that should come from clear need rather than just a desire. IDN WG put in these criteria to get details on why this is needed and an independent panel would evaluate the applicant based upon four questions. In the case of LD PDP is missing a few elements. It is missing one criterion it may be consistent but not the same. Whether that particular condition should be considered by the WG and handed back or whether that is okay. * Diacritics are often not variants of the same word. Case is similar to variants in that sense and are defined in the LGR, whether two labels/words being variants have the same meaning may depend on the language/word itself. The same with diacritics. * Rec 7, should the WG introduce “3.5.2 Explanation of how the primary and variant labels are considered the same” that was missed? Or should this be changed and not ask the same questions and if so, why and what other questions would the WG want to ask? * Idea is to have TLDs to essentially be the same, reiterating the same entity principle and this should be a requirement here. * Does the WG want to allow the TLD to coexist with different meanings or not the intention of the PDP to allow this? * Applicants should prove that these labels are used interchangeably. With the current situation the applicant would not be allowed to proceed. * Does it matter if they mean the same thing, because many have already omitted the diacritic because it has been used in the current TLD form? * Same means interchangeable not necessarily on meaning * Sarmad: variants are two dispositions exist and be blocked or could be allocated. Suggestion from the technical community, allocatable delegations should be minimized. Blocked should be maximized as that is motivated by security concerns and end user confusion. For a small number some may be needed by the community as they are used interchangeably. * Pitinam: SAME means perceived as the same by the community. Does not literally mean the same in meaning. Useful to explain why these are perceived by the community, the meaning is not the same. * There is a narrow scope of this PDP and should stick to well-established community precedents * Summary: most people agree to the requirement from IDN-EPDP re-introduced, one skeptical. * Steve: IG 8 for EPDP-IDNs and the criterion should be standard of general “reasonableness” to make the process not overly onerous, but avoiding proliferation. * IG8: 8.2 The evaluation panel should apply criteria based on a general standard of reasonableness and the criteria must be established during implementation; * IG 11 also had the consistency issue with EPDP-IDNs. Wanted the WG to confirm that additional policy work would not be needed and it could be implemented directed * 1) Deal with consistency language * 2) Proposed outputs on additional tests * Intention is additional analysis in addition to the variants needs to be done but it could be done differently in the case of Latin Diacritics * It appears to be an additional step, but we want it to be the same, but for the variants there is a certain mechanism that will be taken by ICANN and that should be for LD PDP as well. There is not a difference in intent. WORKING SESSION 2 * Began with slides<https://icann-community.atlassian.net/wiki/x/AQANKQ> looking at PR 29. The intention of our recommendation is the same as was with IDN-EPDP, but we changed some wording. Discussion of “in some instances material differences” * Basically the comment from ICANN org is referring to all the linked outputs. It does not only refer to this one. There are additional sentences that LD PDP has added for this recommendation and taken out the RZ-LGR. There is inconsistency in the language but how it applies to our PDP * Staff to adjust wording on the background * IG 41 difference in automatic activation portion that has been taken out for our PDP use. ICANN org noted that this is non-substantive. It is nice to have for org to see where there are changes, but here there is no real change so it should be left as is. * IG 41 Change to AND to be consistent * PR 50 has a substantive issue, with respect to what “necessary information” entails. WG should clarify what is being requested and what this interpretation encompasses. * The reason this was changed was there was a request by the group to be clearer about this outreach that ICANN should do. How much clearer do we need to be? Should the WG go back to the original language of EPDP-IDNs or else provide a bit more detail about what the WG wants to do. * Suggestion that the WG does not fall back on the EPDP discussion by default. * Goal is to not imply consistent with when sometimes the recommendation takes a break. * The WG dedicated a time to conducting outreach to necessary information * PR 51: clarify why the initial source domain name was omitted? This is not a standalone decision and is defined in multiple points. Is there any clarity as to what is omission as substantive or is it clerical? Or is it because of the source-domain logic as to why this omission has happened? This appears to be an oversight and should be corrected * PR 53: not inconsistent even though wording is not the same. We are just clarifying for the scope for our PDP. * Non-substantive comments could change wording, as the intention is the same. * Shift from consistency to a new topic on slides<https://icann-community.atlassian.net/wiki/x/AQANKQ> 12: PR 4 org was asking for clarity on wording change on “immediate next round” * Saewon noted that Kyionna Blaylock made a number of inputs as an individual public comment on many recommendations and did not provide any rationale or proposed changes to it. Michael agreed that further input would be needed, but without additional context, it would be noted but cannot be acted upon. * Language could be cleared up as immediate next round perhaps it was clearer for IDN-EPDP would be necessary for the Next Round, and it could not be started without IDN-EPDP, but it may not make sense for the LD PDP. * Brief discussion on the next round and where LD PDP fits into that, but it may be out of scope for this PDP. * Clarify which round is meant at the time when the policy becomes adopted. It is obvious when the policy is active. Keep the language for now, add footnote, out of scope to define which round this refers to but will be visible when it gets adopted. * PR 6: might want to think about whether the WG intends to allow the withdrawal of the ASCII label in case there is just a single diacritic label left. ICANN org wanted to clarify if this is indeed the case * If there is just one diacritic TLD remaining you could withdraw the ASCII. Since that is the case ICANN org may want to make this a substantial comment. * IG 8: ICANN org’s wording is fine on the non-substantive issue 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 and Public Comment Review Tool
by Saewon Lee March 7, 2026

March 7, 2026

Dear LD PDP WG, A belated Happy New Year! I hope you have all been well and excited to come back after a long “break!” Please find below the Proposed Agenda for the Latin Script Diacritics (LD) PDP WG Working Sessions 1 & 2 during ICANN85 in Mumbai on Saturday, 7 March 2026 (10:30-12:00 IST & 13:15-14:30 IST): 1. Welcome and SOI Updates 2. Overview of LD PDP Initial Report Public Comment 3. Review of LD PDP Initial Report Public Comment 4. Next Steps 5. AOB The links to each session and a more broken-down agenda for each session can be found below: * LD PDP WG Working Session 1: https://icann-community.atlassian.net/wiki/x/AQANKQ * LD PDP WG Working Session 2: https://icann-community.atlassian.net/wiki/x/AYANKQ The Summary Report for the Public Comment is yet to be published (by 9 March), but here is the Public Comment Review Tool where your Support Staff has gathered all the comments and organized them per Output/Sections as well as substantive and nonsubstantive categories: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… This Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> has been developed to facilitate the LD PDP WG’s consideration of the concerns expressed and possible updates to the recommendations from the Initial Report. However, this does not replace the WG members’ obligation to review all input received in full and to indicate if any concerns in this overview have inadvertently been mischaracterized or left out. Please note that all the relevant documents regarding the Public Comment for Initial Report have also been uploaded on the LD PDP dedicated wiki page here: https://icann-community.atlassian.net/wiki/x/BIAUM Should you have any questions or concerns, please don’t hesitate to reach out. We look forward to seeing you all soon! Kind regards, 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>

4 5