June 2025 - Gnso-latin-diacritics

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 11, 2025

June 11, 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