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

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

ICANN85 Policy Outlook Report
by Julie Bisland Feb. 23, 2026

Feb. 23, 2026

Dear All, I am happy to share the ICANN85 Policy Outlook report is now available for download! * Policy Outlook Report: https://go.icann.org/outlook85 Happy reading! With kind regards, Julie -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

LD PDP Working Group Self-Assessment Survey Results
by John Emery Feb. 14, 2026

Feb. 14, 2026

Dear LD PDP WG, Thank you for your participation in the periodic working group self-assessment member survey. I have attached the aggregate survey responses here for your information and will be posted on the public LD PDP wiki space. As a reminder, the LD PDP Initial Report is out for public comment, which closes on 23 February 2026. https://www.icann.org/en/public-comment/proceeding/latin-script-diacritics-… During our two working sessions at ICANN 85 Mumbai, we will be reviewing the Public Comment received. Please be sure to have the sessions added to your calendar: https://icann85.sched.com/ See you soon in Mumbai or virtually! Thank you, 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>

3 2

ICANN85 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland Feb. 10, 2026

Feb. 10, 2026

Dear Councilors, With ICANN85<https://meetings.icann.org/en/meetings/icann85/> just around the corner, please take a moment to read the information below for a seamless and successful meeting. ICANN85 key dates: * Prep Week will take place virtually 23 - 25 February 2026. * Deadline for IN-PERSON registration is 06 March 2026. * ICANN85 will take place in Mumbai 07 - 12 March 2026. On-site registration will not be available. Registration for ICANN85 does not automatically create a user account on sched.com. Instructions and guides to register as well as personalize your schedule can be found on these pages: * Visit this page to REGISTER: https://meetings.icann.org/en/meetings/icann85/ * General information about Mumbai, hotels, transportation and rates, and links to food options can also be found here * The ICANN85 Schedule: https://icann85.sched.com/ * Instructions for personalizing your schedule can also be found here There will be no calendar invitations sent, as the meeting schedule allows you to download all sessions of interest to your individual calendars A reminder to review the Participation Tools page and update Zoom * All sessions that use Zoom rooms, access details will be available 24hrs prior. * Visit the Participation Tools page<https://meetings.icann.org/en/remote-participation> for links to download the latest version of Zoom for access to the ICANN Meeting sessions. * Please see the ICANN Meeting VIRTUAL AND IN-PERSON PARTICIPATION GUIDES in the blue box on the right side of the Participation Tools page for more information on how to get the most out of the virtual meeting tools. * If participating on-site, please read the Frequently Asked Questions here<https://meetings.icann.org/en/meetings/icann85/#faq>. Links to Bookmark ICANN85 Meeting Schedule<https://icann85.sched.com/> ICANN85 GNSO Remote Participation Wiki Page<https://icann-community.atlassian.net/wiki/x/AYBBJ> GNSO Session agendas<https://icann-community.atlassian.net/wiki/x/cYAzJ> For all GNSO meeting-related queries, please email us at: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> and we will be more than happy to assist! Kind regards, GNSO SO/AC Support team -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

FINAL REMINDER! LD PDP Working Group Self-Assessment: Please Complete Before 2 February
by John Emery Jan. 29, 2026

Jan. 29, 2026

Hello LD PDP WG Members, As a FINAL reminder, there is an important ask of the WG during the Public Comment Period to complete a Working Group Self-Assessment. The details are below, but please use this form: https://forms.gle/Hj9SYD6vL1TZi1Js8to complete the survey by 2 February 2026. Please do not share this link outside of the WG! Currently, there are only 5 WG members that have completed the survey. Thank you to those of you who have participated, we encourage full participation by the WG for improvements going forward Thank you for your participation in this brief survey. 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> From: John Emery <john.emery(a)icann.org> Date: Wednesday, January 21, 2026 at 13:03 To: "gnso-latin-diacritics(a)icann.org" <gnso-latin-diacritics(a)icann.org> Subject: Re: LD PDP Working Group Self-Assessment: Please Complete Before 2 February Hello LD PDP WG Members, As a reminder, there is an important ask of the WG during the Public Comment Period to complete a Working Group Self-Assessment. The details are below, but please use this form: https://forms.gle/Hj9SYD6vL1TZi1Js8 to complete the survey by 2 February 2026. Please do not share this link outside of the WG! We encourage you all to participate and will send out periodic reminders until we have full participation. Thank you for your participation in this brief survey. 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> From: John Emery <john.emery(a)icann.org> Date: Monday, January 12, 2026 at 07:43 To: "gnso-latin-diacritics(a)icann.org" <gnso-latin-diacritics(a)icann.org> Subject: LD PDP Working Group Self-Assessment: Please Complete Before 2 February Dear LD PDP WG Members, Congratulations on the Initial Report going out for Public Comment! (Available here: https://www.icann.org/en/public-comment/proceeding/latin-script-diacritics-…) There is an important ask of the WG during the Public Comment Period to complete a Working Group Self-Assessment. The details are below, but please use this form: https://forms.gle/Hj9SYD6vL1TZi1Js8 to complete the survey by 2 February 2026. Please do not share this link outside of the WG! We encourage you all to participate and will send out periodic reminders until we have full participation. On 15 March 2023, the GNSO Council approved<https://gnso.icann.org/en/council/resolutions/2020-current#202303> a process and questionnaire for Working Groups to conduct periodic Self-Assessments during their lifecycle. These periodic surveys are intended to supplement Self- Assessments that already occur when a Working Group closes. The goal is to provide the GNSO Council with important information about how its Working Groups are functioning and whether there are any issues that may need to be addressed as the Working Group proceeds. The LD PDP WG has recently delivered its Initial Report for Public Comment, a key milestone in the WG’s work. This is an opportune moment for the WG to reflect on how the group is functioning and whether there are areas that may benefit from improvement. Please read the following instructions carefully: * The survey tool is provided in Google Forms and is available at this link: https://forms.gle/Hj9SYD6vL1TZi1Js8 The survey is only being shared with the WG Members. Please do not share this link with others. * Background information and instructions are contained within the survey. There is no login requirement, so you will not need user credentials. * This questionnaire is organized into 21 questions divided into five short sections. Simply answer the questions on each page and, when you reach the end, click “Submit.” If you receive a response that “Your response has been recorded,” your feedback was successfully populated. * There is no option to save and continue later. If you would like to browse the questions in advance, they are published here: https://community.icann.org/display/gnsoworkgroupres/Working+Group+Self-Ass… * The survey should take approximately 15 minutes depending upon the number of comments you choose to provide. * The survey will be open for three weeks and will close on Monday, 2 February 2026 at 23:59 UTC. A member of the GNSO policy support staff will monitor the completion process and be available to provide technical assistance if needed. If you are having difficulty with the survey and need assistance, you can email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Additional information about how your input will be used: You may remain anonymous when responding to this survey, meaning that you do not need to provide your name. If you choose to provide your name and/or email address, this will only be seen by staff administering this survey. Staff will only use this information to get in touch with you if there are any follow-up questions after the survey has been administered. After this survey is closed, a report will be produced summarizing the results. The report will include: * Aggregated responses to all questions in which respondents select from a menu of choices or from a numerical scale. * Full text of any narrative responses, such as comments or explanations of their numerical scores. The report will be publicly available: * It will be sent to Council leadership, the PDP leadership team, and the Council liaison to the PDP and will be shared with the full Council, upon request. * It will be sent to the publicly archived Working Group mailing list and posted on the Working Group’s public wiki. Based on the survey results, Council leadership, Council, and/or the PDP leadership team will consider whether there are any changes that should be considered to enhance the team’s operation. Thanks for your willingness to provide feedback about the PDP Team and your participation in it. Kind regards, 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

LD PDP Working Group Self-Assessment: Please Complete Before 2 February
by John Emery Jan. 21, 2026

Jan. 21, 2026

Dear LD PDP WG Members, Congratulations on the Initial Report going out for Public Comment! (Available here: https://www.icann.org/en/public-comment/proceeding/latin-script-diacritics-…) There is an important ask of the WG during the Public Comment Period to complete a Working Group Self-Assessment. The details are below, but please use this form: https://forms.gle/Hj9SYD6vL1TZi1Js8 to complete the survey by 2 February 2026. Please do not share this link outside of the WG! We encourage you all to participate and will send out periodic reminders until we have full participation. On 15 March 2023, the GNSO Council approved<https://gnso.icann.org/en/council/resolutions/2020-current#202303> a process and questionnaire for Working Groups to conduct periodic Self-Assessments during their lifecycle. These periodic surveys are intended to supplement Self- Assessments that already occur when a Working Group closes. The goal is to provide the GNSO Council with important information about how its Working Groups are functioning and whether there are any issues that may need to be addressed as the Working Group proceeds. The LD PDP WG has recently delivered its Initial Report for Public Comment, a key milestone in the WG’s work. This is an opportune moment for the WG to reflect on how the group is functioning and whether there are areas that may benefit from improvement. Please read the following instructions carefully: * The survey tool is provided in Google Forms and is available at this link: https://forms.gle/Hj9SYD6vL1TZi1Js8 The survey is only being shared with the WG Members. Please do not share this link with others. * Background information and instructions are contained within the survey. There is no login requirement, so you will not need user credentials. * This questionnaire is organized into 21 questions divided into five short sections. Simply answer the questions on each page and, when you reach the end, click “Submit.” If you receive a response that “Your response has been recorded,” your feedback was successfully populated. * There is no option to save and continue later. If you would like to browse the questions in advance, they are published here: https://community.icann.org/display/gnsoworkgroupres/Working+Group+Self-Ass… * The survey should take approximately 15 minutes depending upon the number of comments you choose to provide. * The survey will be open for three weeks and will close on Monday, 2 February 2026 at 23:59 UTC. A member of the GNSO policy support staff will monitor the completion process and be available to provide technical assistance if needed. If you are having difficulty with the survey and need assistance, you can email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Additional information about how your input will be used: You may remain anonymous when responding to this survey, meaning that you do not need to provide your name. If you choose to provide your name and/or email address, this will only be seen by staff administering this survey. Staff will only use this information to get in touch with you if there are any follow-up questions after the survey has been administered. After this survey is closed, a report will be produced summarizing the results. The report will include: * Aggregated responses to all questions in which respondents select from a menu of choices or from a numerical scale. * Full text of any narrative responses, such as comments or explanations of their numerical scores. The report will be publicly available: * It will be sent to Council leadership, the EPDP leadership team, and the Council liaison to the EPDP and will be shared with the full Council, upon request. * It will be sent to the publicly archived Working Group mailing list and posted on the Working Group’s public wiki. Based on the survey results, Council leadership, Council, and/or the PDP leadership team will consider whether there are any changes that should be considered to enhance the team’s operation. Thanks for your willingness to provide feedback about the PDP Team and your participation in it. Kind regards, 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 2