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

LD PDP Meeting Notes ICANN83 Sessions 1 & 2
by John Emery June 11, 2025

June 11, 2025

Dear LD PDP WG, Congratulations on completing the worksheet of EPDP-IDNS Phase 1 today! Attached below are the decisions, action items, and notes for the two working sessions today at ICANN83. Outcomes, Action Items, and Notes LD PDP Working Session #1 ICANN83<https://icann-community.atlassian.net/wiki/x/AQBmD> on Wednesday, 11 June 2025 [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant recommendations and wrote the consensus in the decision tab [ACTION ITEMS] 1. None [NOTES] Working Session #1 ICANN83 Slides<https://icann-community.atlassian.net/wiki/download/attachments/208011265/i…> 1. Welcome and SOIs 2. Background and Progress Update of LD PDP * Michael gave background and updates on the progress of the WG to date. 3. Key Achievements a. Mark gave an overview of the successes and the fast pace of this PDP as a credit to all in the WG and staff 4. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> a. Continue with the Review of EPDP-IDNs P1 & P2 Outputs (Worksheet<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> to Leverage Outputs) * 7.11 Comment that this is true unless some of them are terminated and there is a process and it could happen. Possible to be undelegated or frozen. Covered at some other recommendation within EPDP IDN * Do we need this/want this for our PDP as well? Except for the unlikely case mentioned this should be the case. This is reasonable due to same entity principle * Q: Would this also apply to 7.12 and 7.13? A: 7.12 escrow is a different argument they could be escrowed. Agreement this should also be the case for our TLDs * 7.13 Separate files? Agree and copy that policy * 7.14 Concern about the language where there could be new restrictions. Both for the case applied for at the same time, or existing and a variant is added. All of these cases it should apply. * Generally the principle should apply, but could be orange instead of green. We cannot say at this time whether the same contractual agreements will apply even though it may be likely * 7.14 The word allocatable variant is a bit confusing as it means potentially different than its initial meaning. Spirit could be right, but the wording could bring us in the wrong direction. ORANGE cannot copy exactly and rework when we do our recommendations for allocatable variants will have to be rephrased in our context for ALL recommendations * 8.1 comment that this recommendation this was not for management per se, but for security of the whole system. That concern of security will be equally applicable here. PDP may make a decision based on this. * Situation is a bit different here whether we have 1 or 2 diacritics and one could apply for many diacritics we don’t need a restriction here and use a similar approach as IDN EPDP * IDN part was considered because of SSAC report that asks for a limited number of variant TLDs we have not even reached there and there is no SSAC note on this, but likely the principle applies, but we will have to revisit. * Key difference here, is we have deferred discussion on fees and will need to be revisited later * Agreement to revisit this later * 8.2 explanation of meaning that so far there has not been any experience with variant TLDs on user experience and how registrants work with this. ICANN should create some guidelines to check whether variants become active are used in a way that is predictable for user experience * 8.3 Not applicable for our PDP is consensus * 8.4 perhaps nice to have but not necessary, some disagreement here. We do not know yet how the application will work. Whether it will be single application or separate application. Makes sense to postpone this discussion when we have decided the application process. * 8.5 completely does not apply as there is no concept for primary or not. But base ASCII always has to exist. Base ASCII is similar to primary but not the same concept. Which is the base? * Irrelevant whether one is delegated first or not. Not critical in any sense, just the delegation. The rule should be in launch open to public registration, but user confusion could exist. Irrelevant * 8.5 Mark summarized: This is largely not relevant to us. * We may not be able to imagine what question may come tomorrow when we are going. Defer to have more thought on this, how to handle this particular situation. That should be given from ICANN to the registry. Not decide on this, but defer it for later. * The requirement exists for ASCII version only during the application process, but you can delegate later on within 6 months * Mark proposed Framework for this: A) There is no preference or priority between ASCII and IDN; B) The registry is free to decide of their own accord. * 8.5 determined to be not applicable, but perhaps possible to revisit if necessary * 8.6 perhaps could have impact, but not applicable in that it is irrelevant and is already dealt with through the IDN processes. Out of scope or not applicable. We don’t deal with variant relationships and single TLDs * We don’t have to deal with these cases but some TLDs with diacritics may have variants, but it is out of scope for us * However, we may have a similar situation with a unicode situation if then ø is changed in unicode could have a similar impact. What to do with this concrete situation? It could be possible to be a diacritic of an existing TLD. * That is an interesting point given that our rules depend on unicode diacritics. It is possible to make such a change. Additions to this as our cases would remain the same as we would not need to grandfather anything. Outcomes, Action Items, and Notes LD PDP Working Session #2 ICANN83<https://icann-community.atlassian.net/wiki/x/AQBoD> on Wednesday, 11 June 2025 [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant recommendations and wrote the consensus in the decision tab 2. 8.10 agreement on the requirement to retain the base ASCII if you have more than one diacritic 3. 9.1-9.4 specific state labels will not be needed for this PDP 4. EPDP-IDN Phase 1 is completed [ACTION ITEMS] 1. Leadership team to discuss on how best to approach the legal team for the path forward 2. Leadership team to discuss whether to continue with a 25 June meeting due to IGF conflict [NOTES] Working Session #2 ICANN83 Slides<https://icann-community.atlassian.net/wiki/download/attachments/208142337/i…> 1. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> a. Continue with the Review of EPDP-IDNs P1 & P2 Outputs (Worksheet<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> to Leverage Outputs) * 8.7 RZ-LGR are not part of this PDP, this is not relevant to us * The GP and IP should look into the impact of the diacritics as well because there are those cases that are not variants, but cases are possible to be in variant relationship and there could be some grandfathering work to consider. Makes sense to have Latin GP and IP to look into this and ensure how they could affect our cases. * 8.8 There needs to be a mechanism to apply for IDNs so they do not get challenged in the future. There are circumstances where it was approved and correct, so therefore it cannot be revoked. * 8.7 and 8.8 are applicable that TLDs using our policies can ensure to keep using it even in the case if the RZ-LGR were to change * 8.9 applicable * 8.10 here there are lots of concerns from the idea of security and what is a base TLD and variants. Here they are not variants in the technical sense, but we are trying to prevent user-confusion. * Agreement with that position the word MUST prevents owner from exercising ownership, and right could be curtailed * Does not apply for us and would exclude * Sarmad gave some background on 8.10 if primary is taken out there is no mechanism to define the variants, there is some dependency of variants on primary. The basic point to consider whether we consider the second string to have a dependence on the first or if they are on equal footing. In this case if they are independent then they can be independently defined and that constraint would be no longer applicable * If there is any dependence, even if it is not purely independent, it is not the relationship for variants so it should not apply * There is a case where we do need a similar requirement where we have one ASCII and two diacritic versions. If you remove the ASCII and remove enough diacritic versions. Technically this is possible, but not really necessary. If the base ASCII always has to be there * Original impetus was ASCII and diacritic, do we want to revisit that question? This is an edge case and question as to why one would be required to maintain the base ASCII. In IDNs it was needed, but in this case it was just in the Charter. It could be worth revisiting as we dive deeper to park this question and readjust the charter for such an edge case where a set could be without the ASCII * Already agreed to keep the scope narrow in this case and not deviate from this charger and decided that base ASCII would remain there. Ultimately, we stay within this charter to have the base ASCII requirement. We should not revisit this. We do need a recommendation here that base ASCII cannot be deleted unless only a single diacritic version remains * Just diacritic TLDs might be sensible, but it should be kept out of this PDP to not extend the scope * Steve, scope was made intentionally narrow. This is an exceptions procedure. The more you erode it the more you can increase end user confusion. * 8.10 Edge cases to apply for base ASCII and two diacritics and then delete the base ASCII. Would be appropriate to say you cannot delete the base ASCII unless you only have one diacritic remaining * 8.11 See above * Sarmad: case with base ASCII and diacritized version, where you have one ASCII and two diacritics, you should be able to delete a diacritized version so it must apply. * If you have more than two diacritic, you are free to delete one of the diacritic versions but not the ASCII * 8.12 applicable and translation plan wise * 8.13 this applies if it were the same registry, if there is a breach of the agreement then this applies to the whole set. Technical question as to whether this is a variant or not. It remains whether we have a single registry agreement or multiple. Should be postponed. * Sarmad: thoughts on same agreement it is on the primary and agreement. When you sign an agreement it starts with a string as a primary and then other strings are added as an addition. If we have strings added to the same agreement then they will in some cases potentially secondary. Something that the legal team can look at. There is then if we go into a single agreement there is then a potential primary agreement * WE DID AGREE to use a single registry agreement, we did not go into detail about how this would be legally in detail * Steve: when we talk about revocation the single agreement is based on the primary string and if we don't have a unified primary string. If you remove the ASCII or diacritic, you don’t always know the driving string for the primary. The single agreement capturing the relevant strings may not work. * For us to have a single agreement they would have to be all equal to each other * Two aspects: legal it can be a single agreement or different depending on the timings. ASCII TLD in 2026 and diacritic in 2027. Process of approving applications has to go through in both cases. But the same entity principle remains the same. In case of a breach of one agreement it may or may not be applicable to a second application. Technical: we have to see whether there is a dependency on ASCII or diacritic to recheck with SSR issues. Proposal for more deliberations on this particular topic in the future * Breach of a contract applies to one string because you cannot remove base ASCII if there are multiple diacritic versions. * Contracts have many interdependencies, but we should not throw away this idea yet and get the implementation side as to whether or not this is doable * Proposal to bring legal to have a discussion or dialogue. Steve proposed putting specific questions to legal. Could walk through recommendations and see which ones need legal input and get that into a single request to legal * 9.1 Sarmad would be to look at the strings which are being proposed for the IDNs and variants and see which are applicable in this case. Worth looking at this for the SSR panel * Rejected is not a property of the label as such. Blocked is a variant specific term, none of our cases can happen in our cases since we have the same entity principle. * Delegated and Allocated are the terms that would apply to our labels as this is a standard process for any TLD if it is applied for * Sarmad: IDN EPDP there is a policy when someone applies for a variant they have to justify why they need it. It is an exclusive right of someone so they have to argue why it is needed since there is an SSAC advisory where the number of variants need to be minimized. To manage that conservative outlook, it has to be justified that it serves a community etc. There are four questions for each variant that needs to be delegated. Whether those questions will be applicable for similarity cases as well. This is an exceptions process * Saewon in chat: We did actually discuss the RA case in Final Rec 7.1 in the Leadership Meeting/also updating the WG (please see cell F41) where the legal details at this point would not be needed - but this will be further discussed via leadership meeting. This is referenced in final rec 3.5 * Variants have some kind of ontological relationship. Even if it is rejected for any reason related to confusingly similar. If it is the same entity and it is rejected. * Rejected due to applicant not providing enough justification or background as to why they should have that label in the set * These strings are not connected to each other in any legal way, it does not mean that any other entity could apply for that label. * 9.1 not necessary for us to use these label states because these states denotes that it is a property that sticks to the label * Do we need some specific states like they exist in the variant world or whether they make no sense for our case because the labels are not connected to each other anyway. This does not put a sticky state to this label, any other entity could try again. * EPDP-IDNs Phase 1 is completed 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>

1 0

Re: Call for Nominations for Universal Acceptance (UA) Expert WG | DEADLINE 13 June 2025 GNSO Universal Acceptance EWG EOIs
by anil Jain June 10, 2025

June 10, 2025

Dear Philippe, Members of ISPCP Sub: UA WG at gNSO UASG, Organisation leading UA efforts under ICANN is getting restructured as UAEG. Efforts of UASG over last 10 years have created an atmosphere of need, awareness and implementation of UA within ICANN and outside namely IGF/ ITU/UNESCO. ccNSO, ALAC and GAC have already started their UA focussed WGs/committees to ensure that their constituency donot remain untouched with benefits of UA to their community. I , here propose that gNSO, on initiative from ISPCP ,may also start a WG focussed on UA/IDN activities. gNSO represent largest TLDs, Second level TLDs, IDN TLDs, contracted parties and end users( Registrants ) within ICANN. It is not only obligation but duty of gNSO to have its views heard and get UA/IDN policies suited to it community. This initiative will give big push to overall efforts of ICANN and also help ICANN to achieve its 5 Years Strategic Goals wrt UA/IDN. Submitted for kind consideration of Leadership and members of ISPCP. Thanks, Anil Kumar Jain Anil Jain,ITS Chief Executive Officer, National Internet Exchange of India ( NIXI) INDIA On Mon, Jun 2, 2025 at 5:50 PM anil Jain <asdj1990(a)gmail.com> wrote: > Christian, > I am really thankful to you for your kind words. I am totally committed > for the progress of UA to make it Universal in world of Internet to ensure > that every citizen on the earth should be able to use beautiful technology > called “ Internet”. > I am always ready to work whole heartily with you and ISPCP for promotion > and implementation of UA & IDN. > Thanks, > Anil > Sent from my iPhone > > On 2 Jun 2025, at 20:46, Christian Dawson <dawson(a)i2coalition.com> via > ISPCP Private <ispcp-private(a)ispcp.info> wrote: > > > > Dear Philippe and colleagues, > > > Thank you for circulating this exciting development. I’m very enthusiastic > about the formation of this UA Expert Working Group and appreciate the > opportunity for ISPCP to contribute to its success. > > Lars and I were part of the founding class that created the UASG and > helped shape it as members of its original leadership. Having worked > closely on UA issues over the past decade, I would be honored to contribute > to this next chapter in whatever way is most helpful. That said, I want to > express my strong support for both Anil and Nitin—whose contributions to > the UA mission over the years have been invaluable. I’m especially eager to > collaborate with them, should the opportunity arise. > > One area I hope to help with—potentially in coordination with Anil and > Nitin—is exploring meaningful linkages between ICANN’s ongoing UA efforts > and the new initiative I’m helping steward through CODI.global. Our shared > mission to build a multilingual and inclusive Internet presents great > opportunities for alignment, and I’d be glad to help bridge those efforts. > > Ultimately, I believe the ISPCP has one of the strongest UA talent pools > of any SO or AC, and I’m excited to see us playing a central role in the > work ahead—no matter who is selected to represent us formally. > > > All the best, > > Christian Dawson > *Executive Director* > i2Coalition <http://i2coalition.com> > c: 703 623 2612 > > On Jun 2, 2025, at 6:48 AM, anil Jain <asdj1990(a)gmail.com> via ISPCP > Private <ispcp-private(a)ispcp.info> wrote: > > Dear Philippe, > Thanks for sharing this vital information. I am Chair of UASG at present > and served as Chair of UASG Communication group for 3 years. > I think I have relevant experience and outlook to represent gNSO on UA > Expert Group. > I would like to work in newly created UA expert group. > Anil Kumar Jain > Sent from my iPhone > > On 2 Jun 2025, at 13:25, Nitin Walia<nitin(a)data.in> via ISPCP Private < > ispcp-private(a)ispcp.info> wrote: > > > > Dear Philippe > > I would like to formally express my interest in representing the ISPCP in > the newly formed Universal Acceptance (UA) Expert Working Group. > > Having been actively involved with the Universal Acceptance Steering Group > (UASG) since its inception, I bring over a decade of experience and > commitment to the cause. I have had the privilege of serving as Vice Chair > of the UASG and contributing to several of its technical working groups > over the years. My involvement has focused on advancing email address > internationalization (EAI), IDNs, and ensuring a globally inclusive > internet through UA readiness initiatives. > > Given my long-standing engagement with UA, I believe I can offer valuable > insight and continuity to the new working group, and I am keen to support > this important transition. > > Thank you for considering my expression of interest. > > > > > Warm Regards > > Nitin Walia | Director > *Data Ingenious Global Limited* > Tel: +91-141-2554970 > Fax: +91-141-2554972 > LinkedIn <https://www.linkedin.com/in/nitinwalia> Twitter > <https://twitter.com/nitinwalia> > *nitin(a)data.in <nitin(a)data.in> | नितिन(a)xn--c2bd1gb.xn--h2brj9c | **https://* > <https://dil.in/> > *data.in* <https://dil.in/>*Celebrating 25 Years of Innovation and > Excellence <https://www.youtube.com/watch?v=tfvgegx8Uf8>* > *VC*: https://bridge01.videomeet.in <https://cdm5r.app.goo.gl/videomeet> > - *room*: nitin *pwd*: 10000 > Get email id like *me in *your own language, download *DATAMAIL* app from > your iOS or android play store. > *भाषाकीआजादी - *Bridging the Digital Divide, Getting Next billion online > ------------------------------ > *From:* "philippe.fouquart(a)orange.com via ISPCP Private" < > ispcp-private(a)ispcp.info> MailId : [148728638] > *To:* "Christian Dawson <dawson(a)i2coalition.com> via ISPCP Private" < > ispcp-private(a)ispcp.info> > *Subject: *FW: Call for Nominations for Universal Acceptance (UA) Expert > WG | DEADLINE 13 June 2025 GNSO Universal Acceptance EWG EOIs > *Date:* 02 Jun 2025 01:23:03 PM > > Dear ISPCP colleagues, > > > As you may know the UASG has concluded its 10 year mandate and the > activities relative to universal acceptance will take a different form with > the creation of a Universal Acceptance (UA) Expert Working Group. > > > The following call is made to SG/Cs for members to express interest to > join this WG. There will be one representative for each of the 5 interested > SO/ACs. The representative for the GNSO will be selected by the standing > selection committee. More details below and here > <https://www.icann.org/en/announcements/details/icann-call-for-nominations-u….>. > > > > Please express your interest between now and our constituency meeting for > the ISPCP leadership to notify GNSO leadership with our preferred > candidate. > > > Thank you, > > Regards, > > Philippe > > > *From:* Terri Agnew via GNSO-SG-C-Leadership < > gnso-sg-c-leadership(a)icann.org> > *Sent:* Friday, May 30, 2025 8:41 PM > *To:* gnso-sg-c-leadership(a)icann.org > *Cc:* gnso-chairs(a)icann.org; GNSO-Secs <gnso-secs(a)icann.org> > *Subject:* [GNSO-SG-C-Leadership] Call for Nominations for Universal > Acceptance (UA) Expert WG | DEADLINE 13 June 2025 GNSO Universal Acceptance > EWG EOIs > > > *CAUTION* : This email originated outside the company. Do not click on > any links or open attachments unless you are expecting them from the > sender. > > *ATTENTION* : Cet e-mail provient de l`extérieur de l`entreprise. Ne > cliquez pas sur les liens ou n`ouvrez pas les pièces jointes à moins de > connaitre l`expéditeur. > > Dear SG/C Chairs, > > Further to the message from Russ below, to allow time for the Standing > Selection Committee (SSC) to evaluate the UA EWG candidates, the deadline > for GNSO Expressions of Interest (EOIs) is *Friday, 13 June 2025*. This > provides groups the option of using meetings at ICANN83 to discuss > potential candidates, while still allowing time for the SSC to run its > selection process. See the criteria in the announcement: > https://www.icann.org/en/announcements/details/icann-call-for-nominations-u… > . > > Please ensure that GNSO candidates submit EOIs to gnso-secs(a)icann.org no > later than *13 June 2025*. > > > Thank you. > > > Kind regards, > > > Terri > > Policy Team Supporting the GNSO > > > ***** > > > > Hello SO/AC Chairs, > > > I hope you are all doing well and getting ready for a productive ICANN83 > Policy Forum in Prague! I caught up with Alejandra late last week and will > send a note shortly re: our Roundtable Agenda. Before we get to the > Roundtable, I wanted to draw your attention to a recent announcement and > request for support from the SOAC’s related to a new Universal Acceptance > Expert Working Group > > > ICANN org recently announced a call for nominations > <https://www.icann.org/en/announcements/details/icann-call-for-nominations-u…> > for a UA Expert Working Group. The community has been a key contributor > for promoting the Universal Acceptance. ICANN is inviting each SO and AC > for a nominee for this working group. The working group will help us in > achieving a UA-ready world. We recommend that the nominee has expertise in > one or more of the following areas: > > > - Technical challenges and solutions for UA > - Technical training for promoting the use of IDNs and UA > - IDNs and/or Email Address Internationalization > - Internet governance or public policy work related to digital > inclusion and a multilingual Internet > > > > The working group will produce guidelines for ICANN org’s work on UA > adoption, which focuses on the following stakeholders: > > > - Big tech organizations > - Tech developers and system administrators > - DNS industry and related businesses > - Internet governance and policy professionals > > > > The guidelines developed by the WG will be used by the org as it focuses > on implementation and operational efforts to address technical gaps, > technical training, and outreach to drive UA adoption. The UA Expert > Working Group will develop the guidelines over a period of 9-10 months. > After that time the group will be closed, as ICANN org follows up on the > guidelines in its UA implementation work. > > > The working group members will attend regular, likely weekly, meetings and > a few more hours doing the work that is needed to deliver the guidelines. > Community support remains important to achieving UA, and we would very much > like to have someone from each SO & AC join this effort. We request you to > email the nomination by 25 June 2025 to the UAProgram(a)icann.org. > > > Thanks, > > > Russ > > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l`expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d`alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > Do not Remove: > [HID]20250602132303935[-HID] > > [XGENFOOTER] > > [-XGENFOOTER] > > >

1 0

Link to Working Sessions during ICANN83/Proposed Agenda
by Saewon Lee June 10, 2025

June 10, 2025

Dear LD PDP WG, I hope you are well and for those who are attending ICANN83 in person, enjoying the lovely city of Prague! Kindly find the links to the LD PDP Working Sessions 1 & 2 during ICANN83 below: 1. Working Session 1 - https://icann83.sched.com/event/246YY/gnso-ld-pdp-wg-1-of-2 2. Working Session 2 - https://icann83.sched.com/event/246Yb/gnso-ld-pdp-wg-2-of-2 In the links, please refer to the proposed agenda and the pertinent slides. Looking forward to seeing you all in person or online tomorrow! Best, 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

cipher
by Tapani Tarvainen June 9, 2025

June 9, 2025

Dear all, In preparation in our meeting here in Prague, I just have to post this: https://xkcd.com/3054/ Can't wait to see a TLD based on that... :-) -- Tapani Tarvainen

3 2

Post Call | Latin Script Diacritics PDP | Wednesday, 28 May 2025
by Devan Reed May 28, 2025

May 28, 2025

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

1 0

LD PDP WG Meeting #9 Outcomes, Action Items, and Notes
by John Emery May 28, 2025

May 28, 2025

Dear LD PDP WG, Please find the attached outcomes, action items, and notes below: Outcomes, Action Items, and Notes from LD PDP WG Meeting #9<https://icann-community.atlassian.net/wiki/x/AQB-Cg> on Wednesday, 28 May 2025 [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant recommendations and wrote the consensus in the decision tab 2. Consensus not to change the current objections process and to keep the current policies 5.1-5.5 [ACTION ITEMS] 1. Review objections and process as outlined in the Resources<https://icann-community.atlassian.net/wiki/x/AQB-Cg> section of today’s agenda [NOTES] Meeting #9 Slides<https://icann-community.atlassian.net/wiki/download/attachments/176095233/s…> 1. Welcome and SOIs 2. Recap of Meeting #8 a. Outcomes and Action Items * For determination of scope, if strings are visually confusingly similar in the SSR process, our PDP is a way to avoid the objection mechanism that exists there. 3. Charter Question 3<https://gnso.icann.org/sites/default/files/policy/2025/draft/latin-script-d…> Overview of the objection process given for the SSR process * Our PDP cannot change or alter anything about the objections process * Goal of this review is for the WG to understand the existing process * These objections processes will occur prior to LD PDP as detailed in the current AGB draft * Is the notion of precedence important? Can an objector argue that prior rulings were confusingly similar. Based on the arguments of the case at hand regardless of prior? * Each case tends to be an isolate process, but panel works in a consistent manner * Sarmad added that some objections go beyond what SSR does, which is purely visual comparisons. Not related to meaning or sound, which may become relevant through other objection processes. Objections are a much broader area. a. Continue with Review of EPDP IDNs Outputs (Worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> to Leverage Outputs) * 5.1-5.5 does this PDP need any changes to the existing objections processes, if so, they need to be discussed. Otherwise, current objections processes sufficient? Is there anything that would need additional objection processes? Consensus that changing would be too difficult * 6.1 string contention is at the heart of the issue and needs to be tailored to the Latin specific case. * LGR process and not the policy process. If understanding is correct this should be the RZ-LGR process rather than any other process that LD PDP creates * Dealing with both the variants and not the variants at the same time. There is already a subset of variants. Focus on not ending up with language that everything or nothing is a variant. Both working within the limitations of the scope of RZ-LGR and characters we are working with. Word this carefully. * 6.1 nothing should be changed with variant contention sets as RZ-LGR is out of scope. Not applicable as this is an output that LD PDP works within * 6.2 Suggestion that something similar to this will need to be included. Look at the contention set, probably not automatically confusingly similar, process needs to look at all of those. Response that this already exists that if they are confusingly similar they are put into a contention set. Already part of existing policy. * This review process is out of scope. The LD PDP works within the outcome of this process. * 7.2 The principle makes sense that there is some kind of relationship between two or more of the TLDs that we are talking about. There needs to be something written in the contract that those two or more need to be in relationship and will likely need some amendment or new specification * 7.3 similar diacritic version to existing TLD contracts will need to be changed accordingly * 7.4 financial discussions to be discussed as a block later on down the line, once we have all the technical policy decisions in place. Postponed * 7.5 and 7.4 remain pending with the Board currently and are the only pending recommendations from that report * 7.6-7.8 same entity principle applies * 7.9 basic principle applies, but might want further specification in this case. Not an activation of a variant and there is some difference in this. Deal with on a case by case basis. Have to look at exact wording here, not those variant rules. This policy is transferred to a new entity. Same entity principle must be upheld * 7.10 EBERO acronym emergency back-end registry operator explained. * Needs to apply to keep same entity even in EBERO 4. Next Steps 5. AOB Please note there will be not meeting next week to allow for travel to Prague. The LD PDP WG will be holding two sessions at ICANN83 on Wednesday 11 June 2025 at 9:00am and 10:45am Prague local time. Safe travels! 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 #9
by Saewon Lee May 27, 2025

May 27, 2025

Dear LD PDP WG, A bit later this week due to the public holiday here in the US yesterday, but please find below the proposed agenda for LD PDP WG Meeting #9 on Wednesday, 28 May 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #8 * Outcome and Action Items 1. Charter Question 3 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * Overview of Objection Process * Continue with the Review of EPDP-IDNs Outputs (Worksheet [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> to Leverage Outputs) 1. Next Steps 2. AOB The LD PDP WG Charter [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> and the Worksheet with SubPro/EPDP-IDNs Outputs [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> have been hyperlinked for your reference and the Charter Questions can be viewed on page 2. Please also see all relevant/background documents to this PDP on wiki here [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/2wP…>. See you all tomorrow! 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>

1 0

Objections and Appeals
by Saewon Lee May 23, 2025

May 23, 2025

Dear LD PDP WG, TGIF! In order to effectively facilitate discussions for next week’s WG meeting (Meeting #9) on EPDP-IDNs P1 Section 5 (Objection Process), Staff would like to share the following 2 page document on “Objections and Appeals” that presents the process in a nutshell: https://newgtldprogram.icann.org/sites/default/files/documents/objections-a… This document and other Applicant Guidebook (AGB) Resources can be found here: https://newgtldprogram.icann.org/en/application-rounds/round2/agb/resources For more details/background documents on the process(es), kindly also refer to the wiki under “Understanding String Similarity Review and relevant processes”: https://icann-community.atlassian.net/wiki/x/2wPVBg Best 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> From: John Emery via Gnso-latin-diacritics <gnso-latin-diacritics(a)icann.org> Reply-To: John Emery <john.emery(a)icann.org> Date: Wednesday, May 21, 2025 at 10:34 AM To: Juliana Harsianti via Gnso-latin-diacritics <gnso-latin-diacritics(a)icann.org> Subject: [Gnso-latin-diacritics] LD PDP WG Meeting #8 Outcomes, Action Items, and Notes Dear LD PDP WG, Please find the attached Outcomes, Action Items, and Notes below: Outcomes, Action Items, and Notes from LD PDP WG Meeting #8 [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/TIB…> on Wednesday, 21 May 2025 [OUTCOMES] 1. Filled in Spreadsheet [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…>of relevant recommendations and wrote the consensus in the decision tab [ACTION ITEMS] 1. WG members to take some time read 4.4 for the beginning of next call from the spreadsheet [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> 2. WG members to read Challenge Mechanism for String Similarity Review<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/downl…> (Draft AGB Text) 3. WG to review the existing body of work related to CQ 3 (EPDP-IDNs P1 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…>-2 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…>) to continue filling out the worksheet next week [NOTES] Meeting 8 Slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/space…> 1. Welcome and SOIs 2. Recap of Meeting 7 a. Outcomes and Action Items * Filled in Spreadsheet [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…>of relevant recommendations and wrote the consensus in the decision tab 3. Charter Question 3 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> a. Continue with Review of EPDP IDNs Outputs (Worksheet [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> to Leverage Outputs) * Reminder that discussion of fees will be deferred until later in the process * Began filling in at 3.14 * 3.18 discussion of Reserved Names which is now known as “Blocked Names”, it is a finite list and not applicable. * 3.20 N/A discussion that this is not an issue as long as the applied for string is not a variant of blocked name. If base ASCII is already reserved. Key is that we do not provide any specific advice to override it * 3.21 (Determined prior and not applicable as it already applies) discussion of possible cross between this and current work based on accented versions in latin script. Do we just leave as is? Would we need any special treatment in these cases? It would apply in these cases as well as long as it meets the eligibility through other recommendations. If this case comes under recommendations of this PDP then those apply here as well * 3.22 (Determined prior and not applicable as it already applies) discussion that mandatory string requirements must apply. Wherever it says respect IDNA rules we should keep by default unless there is an overwhelming reason for us not to do that * Question: we know that the RZ-LGR is an authoritative source for possible strings. Do we have in mind a list of possible diacritic versions of Latin strings that would be available for application? A: we have list based on character basis https://github.com/mark-wd/ASCII-Unicode-Diacritics-Analyzer-Tool/ [github.com]<https://urldefense.com/v3/__https:/github.com/mark-wd/ASCII-Unicode-Diacrit…> . This is the finite list of what is possible to apply for. That would also have to meet the mandatory string requirements for eligibility. * Since this is not authoritative, this is still just a guide so people can look at characters that would fall into PDP rules. For authoritative definition it would be the Unicode table. * Will there be a way that people can insert something to find out whether it is eligible or not? An authoritative guide for applicants in the future. 3.22 has to apply because you cannot go outside of that. * The tool is helpful if we are in full agreement with Unicode, there might be cases in which that is specific to DNS and root zone, underlying question, are we in full agreement with Unicode? If we are then the list is sufficient * 3.22 if we don’t say anything, are the general rules still applicable? Or does it make sense to clearly state that we are not changing it. Staff concurs that it is an overlap ASCII and diacritic are applied for gTLD string and would be applicable without stating it explicitly * 3.23 (Determined prior and not applicable as it already applies) * 3.24 Seems sensible to not relitigate. Where the label becomes potentially ineligible due to string similarity. Some of these are not related to the step in that process. RZ-LGR is more fundamental check than string similarity. * 3.24 (Determined prior and not applicable as it already applies) String Similarity Review * 4.1 Discussion this could open to a range of are we making the two with diacritics confusingly similar or do we need another set of criteria? This needs to be discussed once we finish with this section of looking at EPDP-IDNs rules * Initial reaction would be that this should apply to any applied-for string. After String Sim applies there might be certain other things we can do. If this causes a situation that it is listed as similar and therefore blocked. Then maybe yes we should say something about it. Principles don’t change, but we might have something to say that this PDP creates an exception, there could be remedies applied to it * This feeds into the process that creates the reasons for this PDP, more of an input to the PDP rather than the PDP trying to do. SSR and RZ-LGR gives us text to work with but don’t want to change as such * This describes the process of SSR, not what happens as an outcome. This is only a description of the process and will not do any recommendations to change it * 4.2 SSR is a given fact, and we work with the results but will not change it * 4.4 Take some time read 4.4 for the beginning of next call * 4.4 if this string compares with different categories, then it can result in different actions. Wouldn’t it be items that need exceptions for this PDP? Perhaps this is where the PDP might need to look in detail for this? At some point we have to make our rules, and this might be the place for it. Should we create a new section for this or if this is the right place to make those rules? * These rules are the ones that feed into the current PDP then the current PDP says given these rules and outcome then how to deal with particular subset of outcome. These rules would apply, and the current PDP would be more how to deal with output of these rules and not to change the rules themselves * Be careful to not change the base rules, perhaps those that we have discussed to accept the base rule, but create exceptions for this PDP, indicate somehow that when we do create the exception to see if it applies effectively to those that we are marking. Objection Process * 5.1 may have our own objection process, but that would be later in the process as SSR would be out of scope. If it is rejected due to SSR and it is a diacritic then we would make new rules * Principle should apply but we are not dealing with variant labels. Are existing objection processes enough to deal with everything already? * Discussion not of SSR, it is the visually confusingly similar process. Perhaps look to the string confusion objection scope to see if that covers it. 4. Next Steps * WG to review the existing body of work related to CQ 3 (EPDP-IDNs P1 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…>-2 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…>) * Can we clarify the question from Bill that String similarity and confusing similarity are same OR different? To be discussed next week! 5. AOB 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>

1 0

ICANN83 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland May 22, 2025

May 22, 2025

Dear all, With ICANN83<https://meetings.icann.org/en/meetings/icann83/> just around the corner, please take a moment to read the information below for a seamless and successful meeting. REGISTER NOW! DEADLINE FOR IN-PERSON REGISTRATION IS 08 June 2025! * Sign into Your ICANN Account or create an account here<https://account.icann.org/login>. * Register by selecting the Meeting Registration tile. * Click on the Registration link. NOTE: On-site registration will not be available. In-person attendance registration remains open until 08 June. After 08 June, only virtual participation will be open for continued registration. Before creating your schedule, please read this page carefully: https://meetings.icann.org/en/remote-participation. If participating on-site, please read the Frequently Asked Questions here<https://meetings.icann.org/en/meetings/icann83/#faq>. CREATE YOUR MEETING SCHEDULE * Access the schedule here<https://icann83.sched.com/>. The schedule shows up with blank circular radial buttons to the left of each session. Hover over the radial button and click “ADD TO MY SCHEDULE” or just click to add the checkmark. * Once you’ve selected all sessions, click the My Schedule Tab next to “Event Schedule”. * Click the Phone icon, “Mobile App + iCal” (located on the right side of the page) * At the bottom of that page, “Export Calendar”, click the “My Schedule” link. When the .ics is exported, add it to the appropriate calendar. OR, after exporting, drag and drop the .ics file into your calendar. * For helpful video tutorial, see https://sched.com/guide/your-personalized-schedule/ * Please remember, for security purposes, participation links will be posted 24-hours prior to the session start times. There will be no calendar invitations sent, as the meeting schedule allows you to download all sessions of interest to your individual calendars Review the Participation Tools and update Zoom * All sessions will use Zoom rooms. Access details are 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 for more information on how to get the most out of the virtual meeting tools. Links to Bookmark ICANN83 Meeting Schedule<https://icann83.sched.com/> ICANN83 GNSO Remote Participation Wiki Page<https://icann-community.atlassian.net/wiki/x/AQDfCw> GNSO Session agendas<https://icann-community.atlassian.net/wiki/x/IoDhCQ> REMINDER: Walk-up and registrations after 08 June will not be accepted. To make the most of Zoom’s features, update to the latest version of Zoom<https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0060716>. For all GNSO meeting-related queries (RP or others), 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 Sr. Coordinator (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

Post Call | Latin Script Diacritics PDP | Wednesday, 21 May 2025
by Devan Reed May 21, 2025

May 21, 2025

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

1 0