July 2025 - Gnso-latin-diacritics

Meeting #14 Outcomes, Action Items, and Notes
by John Emery July 30, 2025

July 30, 2025

Hello LD PDP WG, Please find the attached outcomes, action items, and notes from the 30 July 2025 meeting #14 of the LD PDP WG. Meeting #14 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/37198241…> [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant recommendations and wrote the consensus in the decision tab 2. Single application was the consensus for Latin diacritics from EPDP-INDs Final Recommendation 3.4 [ACTION ITEMS] * WG to review upcoming TBD items in the worksheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #13 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 looks at the second level variant management Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * 3.4 One application administratively simplified, but cost implications similar to IDNs for pricing. * One application per TLD they could go through if they are not found similar in String Sim Eval. Then our PDP would come into effect. If there were a single application, it would mean that the applicant would beforehand state they intend to run the TLDs as a bundle * There could be policies that unlike variants there would not be disposition values of blocked and allocatable. In the variant case it is that there is a primary, if that is undelegated it would need to be removed * Potential cases where a diacritic version is not visually confusingly similar string, then they should be completely different applications. This issue links to a number of other issues and cannot single this issue out without 2-3 of the other items * Unclear whether we have a single application or multiple. Single has some benefit at the time of application can know they will be running bundled and need and RSP capable of IDN level 3 support to run variant TLDs. Finding that after the application might be more difficult * Sarmad: thinking whether this remains in the scope? Scope for those strings that go through the similarity process and found similar and cannot proceed, it is no longer in the exceptions process. Paired up front there is a possibility that non-variants and non-similar applications can be done. We are pairing strings not directly in scope of this PDP * Whether they are similar or not may be less applicable if it is one application * Sarmad: still should be a mechanism for two different applicants with different strings only in diacritics even with same ASCII not found similar by SSR. * 3.4 both for single application (but what if they are not confusingly similar) two applications what if they are confusingly similar and then combined into a single contract. * Suggestion to go with single application, but if found not confusingly similar applicant A has option to separate it into two applications. * In the chat: I think I’d be more comfortable if there was no visual similarity test, but Latin strings with and without diacritics were always considered part of the same group. Just as with IDN variants in non-Latin scripts — even if there is no visual similarity, a string and its variant are considered as part of the same group. * Basically, the same as IDN variants, because LGR is decided, then we have to have a visual similarity test, otherwise we cannot know if they can exist separately * Can’t and don’t want to change the LGR to make them variants of each other. * Example discussed: Just as a fictional illustration, as I understand it, if: Applicant A applies for: .accent + .ᶐḉčḗňṯ Applicant B applies only for: .accent Applicant C applies only for: .ᶐḉčḗňṯ If the 2 strings are NOT considered visually confusingly similar, then it is possible that Applicant A will need to go into 2 different auctions against Applicants B and C separately. * Based on the vote on the call, same application is the consensus * The same application with the possibility to be split into two in the future. This is key principle * Sarmad: What is the criteria for two different strings in the same application. They have the same base characters and only diacritics differently. Splitting one application into two applications might be extremely difficult. * Sarmad: if someone is applying with clear intention up front to run these together, * but if we don’t allow the splitting then we would allow applications then something could be bundled that is not confusingly similar * Splitting up applications seems too difficult. If the applicant wants two strings if it is in contention with two different applications then the same string goes through an application process. There can be multiple strings in contention sets * Single application split into two applications may be impossible or at least problematic * Kept as single application and can revisit if there will be a split up after we have answered the other questions, such as pricing * 3.5 there needs to be some justification for meaning or intended meaning for each label how the primary and variants are considered the same. Might not be necessary, the reason ASCII is a fallback presentation * Bundle seems logical as a concept * Sarmad: 3.5 for variants was based on SSAC recommendations that said having strings which are “administratively put together” and have multiple strings at top level and second level it creates a lot of domain names bundled together and that can potentially cause management challenges. The number of domain names associated and managed by same registrar should be minimized. One mechanism to minimize that was for a clear reason to justify each variant string. That allows to not arbitrarily expand number of variants. Take those only needed. In this case it could be a similar situation where you could have an arbitrary number of diacritized version, then they could be bundled then it creates a similar problem that SSAC was addressing. Something similar is needed for a justification for each diacritic version * We would need a similar justification for 3.5 for our case with a different wording * Implementation 3.6 as a consequence of 3.5 that is also true for us * 3.21 should not be any exceptions for those processes and just follow existing rules for protected strings * All the cases possibly could exist, there is no new policy as we are making an exceptions process if two otherwise available strings are objected because they are too similar to each other. Anything related to protected strings would be caught before our policy would come into effect. * 3.25 this is about the .Brand TLDs that they have an applied for TLD they are allowed to change their applied for TLD if it matches their brand. Do we want to have the same exception process here to include the diacritic version? 1. Next Steps 2. 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

Post Call | Latin Script Diacritics PDP | Wednesday, 30 July 2025
by Devan Reed July 30, 2025

July 30, 2025

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

Apology for today meeting
by Juliana Harsianti July 30, 2025

July 30, 2025

Dear Terry and LD-PDP team, I would like to apologize for today's meeting. I couldn't attend the meeting since it's conflicting with other schedule. Best regards, Juliana

1 0

Proposed Agenda for Meeting #14
by Saewon Lee July 29, 2025

July 29, 2025

Dear LD PDP WG, I hope you all took great advantage of the week off! Please find below the proposed agenda for LD PDP WG Meeting #14 on Wednesday, 30 July 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #13 3. Charter Question 3 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * Review of TBD Items 1. Next Steps 2. AOB As always, 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 Wednesday! 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

Re: Outcomes, Action Items, and Notes from Meeting #13 on Wednesday, 16 July 2025
by Saewon Lee July 18, 2025

July 18, 2025

Dear LD PDP WG, Pursuant to Action Item #1 below from Meeting #13, please find in the link the updated slides: https://icann-community.atlassian.net/wiki/x/OQDqE Have a great weekend and a week off everyone! 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> From: John Emery via Gnso-latin-diacritics <gnso-latin-diacritics(a)icann.org> Reply-To: John Emery <john.emery(a)icann.org> Date: Wednesday, July 16, 2025 at 4:52 PM To: "gnso-latin-diacritics(a)icann.org" <gnso-latin-diacritics(a)icann.org> Subject: [Gnso-latin-diacritics] Outcomes, Action Items, and Notes from Meeting #13 on Wednesday, 16 July 2025 Dear LD PDP WG, Please see below the Outcomes, Action Items, and Notes from Meeting #13 [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/OQD…> on Wednesday, 16 July 2025: Meeting #13 Slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/space…> [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] * Staff to make a note on slide 7 for yilmaz dot less i example * No meeting next week 23 July due to leadership absence, calls to resume 30 July * All to review TBD items in spreadsheet [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #12 * Reviewed agreement on SLD cases * Case 1.2-1 variants at the second level with IDNs * Yilmaz example with dot less i to be updated * Query about second level for ASCII and second level there is no single entity principle as that is up to the registry. * Strongly encourage registries to apply this perhaps in the language without making it a rule * Sarmad: in this context there is already another document for IDN implementation guidelines. Section 2.5<https://www.icann.org/en/system/files/files/idn-guidelines-22sep22-en.pdf> talks about confusability of labels. Generic recommendation from Seb may already be there; it can be done in the context of the guidelines from here. 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 looks at the second level variant management i.Filled in worksheet [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> * Continued on implementation guidance 12 on Uniform Rapid Suspension System. For variants the same entity does not apply to all of them. Complainant must submit every domain they would like suspended * Diacritics are a much larger variant set than IDNs, if there is another top-level linked to another diacritic, at the second level variants are solved by IDNs. Only the same entity principle is only at the top-level. * Recommendation 13: if same entity applies to new strings work then the dispute resolution providers should be apprised of these as well. * Suggestion to use Mark’s R-tool since it is internal that it might be helpful like an IDN table. We don’t actually need to know what diacritics exist as the same entity is only at the top level, the second level is out of scope. IANA database would show if there is a diacritic TLD of that * If this is not enforced by the registry for any top level domain. There is a solution for top-level domain, but not for second level * Recommendation 14 EPP extension is currently being worked on for IDNs. Suggestion to align with that. * Sarmad: question about a similarity relationship vs. a variant relationship and is that easily portable to this scenario? Michael: it is currently still in development perhaps calling it connected, but aligning will make life easier * Sarmad: could be an implementation guidance to * Implementation guidance 15: general agreement, Sarmad clarified if this is related to EPP or RDS. Can’t be EPP and this is other entities and end-users not language between registries and registrars * Final Recommendation 16: Yes to IANA transparency * Implementation Guidance 17: also valid for our cases with a tweak of wording since it is not about variants, but diacritics * Final Recommendation 18-21 all IDN implementation guideline related * Sarmad: IDN guidelines are for gTLDs and ccTLDs and developed by group from both groups. The work is largely focused on second level implementation of IDNs, in that sense, unless we want to talk about 2nd level IDN implementation work, otherwise this will not be relevant * Diacritics at second level are not really regulated, it is something that could be included in IDN implementation guidelines as these problems already exist now with single TLDs 1. Review of TBD Items * PDP is about creating an exception process for one specific problem. If you apply for two TLDs where those are diacritics and not variants, you can apply for each TLD, but there is a high chance that one will be rejected because it is too similar. We want to avoid this rejection and make it possible for entities to apply for both TLDs. We are not trying to make any further rules that make this easier or to encourage people to do this if the rejection would not take place. Solve problem of rejection, but not making it easier than that * First discussions to note that we have voluntarily limited ourselves to the notion of what a diacritic is. But other groups may study those separately with the same sort of method when applied to them. By not making rules about them, not saying it should not be dealt with at all, but it is sensible to deal with in the future. It is out of scope * 3.4: One application for all TLDs or separate applications: Variants, it was combined in a single application. Single application suggested. * Wording easier to be bundled in same entity, but can be problematic at string similarity review * Suggested: have a single application and by that already states that those TLDs will be run with the rules of the PDP, string sim check would not be necessary, it would make this known to the applicant. Idea is to write with the application if you want to use the PDP rules or not * Steve clarified thinking about the question makes sense to signal up front that they want to question that applicants for ASCII and LD are making a planned decision. Applicant for ASCII and LD are not waiting for a string sim review to decide to operate it in that fashion. 4. Next Steps * No meeting next week 23 July due to leadership absence 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

Post Call | Latin Script Diacritics PDP | Wednesday, 16 July 2025
by Devan Reed July 16, 2025

July 16, 2025

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

Outcomes, Action Items, and Notes from Meeting #13 on Wednesday, 16 July 2025
by John Emery July 16, 2025

July 16, 2025

Dear LD PDP WG, Please see below the Outcomes, Action Items, and Notes from Meeting #13<https://icann-community.atlassian.net/wiki/x/OQDqE> on Wednesday, 16 July 2025: Meeting #13 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/28377093…> [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] * Staff to make a note on slide 7 for yilmaz dot less i example * No meeting next week 23 July due to leadership absence, calls to resume 30 July * All to review TBD items in spreadsheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #12 * Reviewed agreement on SLD cases * Case 1.2-1 variants at the second level with IDNs * Yilmaz example with dot less i to be updated * Query about second level for ASCII and second level there is no single entity principle as that is up to the registry. * Strongly encourage registries to apply this perhaps in the language without making it a rule * Sarmad: in this context there is already another document for IDN implementation guidelines. Section 2.5<https://www.icann.org/en/system/files/files/idn-guidelines-22sep22-en.pdf> talks about confusability of labels. Generic recommendation from Seb may already be there; it can be done in the context of the guidelines from here. 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 looks at the second level variant management i.Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * Continued on implementation guidance 12 on Uniform Rapid Suspension System. For variants the same entity does not apply to all of them. Complainant must submit every domain they would like suspended * Diacritics are a much larger variant set than IDNs, if there is another top-level linked to another diacritic, at the second level variants are solved by IDNs. Only the same entity principle is only at the top-level. * Recommendation 13: if same entity applies to new strings work then the dispute resolution providers should be apprised of these as well. * Suggestion to use Mark’s R-tool since it is internal that it might be helpful like an IDN table. We don’t actually need to know what diacritics exist as the same entity is only at the top level, the second level is out of scope. IANA database would show if there is a diacritic TLD of that * If this is not enforced by the registry for any top level domain. There is a solution for top-level domain, but not for second level * Recommendation 14 EPP extension is currently being worked on for IDNs. Suggestion to align with that. * Sarmad: question about a similarity relationship vs. a variant relationship and is that easily portable to this scenario? Michael: it is currently still in development perhaps calling it connected, but aligning will make life easier * Sarmad: could be an implementation guidance to * Implementation guidance 15: general agreement, Sarmad clarified if this is related to EPP or RDS. Can’t be EPP and this is other entities and end-users not language between registries and registrars * Final Recommendation 16: Yes to IANA transparency * Implementation Guidance 17: also valid for our cases with a tweak of wording since it is not about variants, but diacritics * Final Recommendation 18-21 all IDN implementation guideline related * Sarmad: IDN guidelines are for gTLDs and ccTLDs and developed by group from both groups. The work is largely focused on second level implementation of IDNs, in that sense, unless we want to talk about 2nd level IDN implementation work, otherwise this will not be relevant * Diacritics at second level are not really regulated, it is something that could be included in IDN implementation guidelines as these problems already exist now with single TLDs * Review of TBD Items * PDP is about creating an exception process for one specific problem. If you apply for two TLDs where those are diacritics and not variants, you can apply for each TLD, but there is a high chance that one will be rejected because it is too similar. We want to avoid this rejection and make it possible for entities to apply for both TLDs. We are not trying to make any further rules that make this easier or to encourage people to do this if the rejection would not take place. Solve problem of rejection, but not making it easier than that * First discussions to note that we have voluntarily limited ourselves to the notion of what a diacritic is. But other groups may study those separately with the same sort of method when applied to them. By not making rules about them, not saying it should not be dealt with at all, but it is sensible to deal with in the future. It is out of scope * 3.4: One application for all TLDs or separate applications: Variants, it was combined in a single application. Single application suggested. * Wording easier to be bundled in same entity, but can be problematic at string similarity review * Suggested: have a single application and by that already states that those TLDs will be run with the rules of the PDP, string sim check would not be necessary, it would make this known to the applicant. Idea is to write with the application if you want to use the PDP rules or not * Steve clarified thinking about the question makes sense to signal up front that they want to question that applicants for ASCII and LD are making a planned decision. Applicant for ASCII and LD are not waiting for a string sim review to decide to operate it in that fashion. 4. Next Steps * No meeting next week 23 July due to leadership absence 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

Proposed Agenda for Meeting #13
by Saewon Lee July 14, 2025

July 14, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #13 on Wednesday, 16 July 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #12 3. Charter Question 3 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * Review of EPDP-IDNs P2 Outputs (Worksheet [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> to Leverage Outputs) * Review of TBD Items 1. Next Steps 2. AOB As always, 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 Wednesday! 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

same entity principle
by Tapani Tarvainen July 10, 2025

July 10, 2025

Just to clarify my point about same entity principle on registrants I made during the call: Assume someone gets .muller and .müller and wants to give mark.muller and mark.müller to different people. The rule proposed would require a single registrant, but it would be easy enough to work around: simply form a legal entity that acts as the registrant and lets Mark Muller and Mark Müller have their own domains without being official registrants. Mark Müller and Mark Muller could do it by themselves if they agree, but more likely the registrar would simply offer it as a service, with a subsidiary that acts as the registrant. Or an independent company could do it. If we'd insist on matching DNS records too it could still be worked around, then you'd just have to have common hosting at least as a redirector. Thus the same entity principle would not be really effective on registrants, it would just cause extra complications and cost for people it affects. Of course this could be seen as a positive, creating new business opportunities, but on general principles I would not like to see a situation where actual users of domains are hidden behind yet another layer of obfuscation, and especially not an ICANN policy that in effect forces them to. So while I like the same entity principle for registries and registrars, I would leave it on registrant level up to the registry or registrar, possibly with a policy to be specified in the registry agreement. -- Tapani Tarvainen

6 8

LD PDP 9 July 2025 Meeting #12 Notes
by John Emery July 9, 2025

July 9, 2025

Dear LD PDP WG Please find attached below the meeting notes from the 9 July 2025 Meeting #12 of the LD PDP WG: Outcomes, Action Items, and Notes from Meeting #12<https://icann-community.atlassian.net/wiki/x/T4DpE> on Wednesday, 9 July 2025 Meeting #12 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/28373819…> [OUTCOMES] 1. Consensus from Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/28373819…> page 7 & 8. Example 1.1 and 1.2 the same entity principle applies. Example 1.3 there will be nothing done in this PDP, registries are free to have their own rules. 2. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant recommendations and wrote the consensus in the decision tab [ACTION ITEMS] * AI: staff and leadership to redo the slide 7 for the 1.2 example for a new Latin example and non-Latin examples [NOTES] 1. Welcome and SOIs * Anil Jain noted his updated SOI 2. Recap of Meeting #11 * Reviewed Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/28373819…> * Discussed examples from last week for second-level management from slides 6, 7, and 8 * Discussion of same entity principle for case 1.1 test.example and test.éxample * Query about what cc’s use on the same entity principle rule for comparison * Case 1 and 1.1 should be the same entity principle? Debate amongst the group * Sarmad: IDNs have been registered at 2nd level for some time now. For PDP work, there has been a Board resolution<https://www.icann.org/en/board-activities-and-meetings/materials/approved-r…> in 2019 that basically asked GNSO and ccNSO to consider variant TLD recommendations. There were different ways this has been done before but post-2019 it should be considered. This has been done by both GNSO and ccNSO. Suggests that variants at the top level and second level (strings considered “the same” by end users), therefore the recommendations since these are the same strings they should go to the same registrants. Variants at the second level also mean that those are the same strings or code points for the end users. Variants by definitions are the same strings and therefore should go to the same registrant. * Sarmad: There are separate clauses prior to 2019 that IDN-EPDP where different registrants can remain, but new registrations should be to the same registrant * Suggestion same entity principle must be for 1.1 as well as 1, a bit of an impasse * Rough consensus emerged that case 1.1 test.example and test.éxample should be same entity principle * 1.3 ASCII and diacritic version only for the top level required, now considering an extra layer on the second level * Debate about having some kind of case-by-case basis or doing it across the board * Taling about tLDS that get an exemption process from being rejected for TLDs * Sarmad: 9 cases: {same, variant, similar/diacritic}.{same, variant, similar/diacritic}: 3 possibilities at the top level and 3 at the second level. Some of those cases are already clear policy for EPDP-IDNs and SubPro. Some additional cases discussing here. Suggested that in discussing the different cases we clearly use one of the packets and then have the rules and not mix those. * Summary: discussions majority seems to say we don’t want rules for 1.3 case, registries are free to handle those ASCII/diacritics if they want to make them as variants or same entity, it is up to them. 1.1 majority consensus there is same entity principle. 1.2 We can't make any rules because of the already existing EPDP-IDN rules because they are already variants. Cases where it is already decided that the 2nd level are variants of each other tesst.example vs. tesst.éxample and teßt.example and test.éxample. * Consensus 1.1 and 1.2 should be the same entity with an objection from Tapani * AI: redo the slide 7 for the 1.2 example for Latin example and non-Latin examples 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 looks at the second level variant management i.Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * Final Recommendation 8: does not only refer to 2nd level variant set, it also says a given gTLD and its delegated gTLD variant labels. In addition it is also the diacritized versions and not necessarily the gTLD delegated variables. Must change wording to make it applicable for LD PDP * Final Recommendation 9: similar argument as 8, this is only the context of variants, if it is beyond variants then the language will need to be updated to extend it to Latin diacritized versions. This applies to most recommendations here in the final language. * Applicability for the whole lifecycle and not just in the creation process. Agreement that the meaning is applicable and the wording is fit for purpose. * Recommendation 10: another case of language harmonization for same entity principle * Recommendations 10-12 are bundled to change wording, but applicable to LD PDP * Recommendation 12: In theory it is possible to have different trademarks for the same word with and without diacritics. There could be legal enforcement higher than ICANN rules for the exemption process. But this is likely an exceptional case. URS is differing because URS is on suspension model and does not break the same entity rule and there is no domain transfer. 4. Next Steps 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