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

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

Aug. 13, 2025

Dear LD PDP WG, Please see attached the Outcomes, Action Items, and Notes from Meeting #16<https://icann-community.atlassian.net/wiki/x/AQAvFg> on Wednesday, 13 August 2025: Meeting #16 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/37217894…> [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant TBD recommendations and wrote the consensus in the decision tab [ACTION ITEMS] * WG to review upcoming TBD items in the worksheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * Leadership to discuss if there needs to be an interim update to SO/ACs on progress * Staff and leadership to make slides laying out current options for cost and inquire about cost recovery * WG to think about pricing contracts to find a resolution that is workable and that most agree to [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #15 * Exceptions process decided last week explained * Query about an interim update to SO/ACs 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 TBD items i.Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * 8.4 timeline should apply for time from contract to delegating the TLD should be consistent. Does not make sense to make any exceptions, just follow standard process * 8.5 explanation for leaving delegation to registry decision (same time or independently) as long as total time is adhered to. * Do we need a restriction for our applicants to delegate at the same time, certain order of delegation, or up to the registry? There should not be any restriction was the consensus * Sarmad: One of the motivations behind the IDN EPDP recommendation was to clarify a primary and variant, variants do not need to wait for primary to be delegated. In this case as well, two strings tied together ASCII and diacritic, then it would be a similar case that any could proceed independently of each other * 8.10 this was decided in IDNs that variants are a property of the primary TLD and if that is removed all variants lose their connection and cannot exist. The primary holds together the variant set, when it is removed, the variant falls apart * If there is a dependency on the ASCII TLD label, then maybe something similar may need to apply especially if it is one application. * Sarmad: Beyond the technical side there is a contractual side, if there is a single contract, then the contract would normally contract a single string with a tied string as an appendix, if a string goes away then the others would have to go away as well. * There may be technical reasons for keeping the bundle unbundled, here we are trying to prevent user confusion if one disappeared, there is no user confusion. There are not good reasons for doing it, but the contractual part, unicode could change. There could be a time where the that could * Steve: The previous agreement principle of primary string is not exactly applicable. General principle if there is only 1 diacritized version left you can drop the ASCII. If there are 2 or more, then you cannot drop the ASCII. * Already the general requirement for the whole exception process is that one ASCII version must always exist. If we were to allow switching in the contract, we would need the requirement that it is only possible to drop ASCII if only a single diacritic version is left as a standalone TLD * 8.10 Remove ASCII in the case that a single diacritic exists, if more than one, it would be required to remove all but one of the diacritics * 8.11 agreement noted in worksheet * 8.13 Sarmad: if a single contract and a breech, it affects all TLDs in that contract * 3.11 4 variants for the price of one? Would be fair, but nearly impossible, there is some cost in evaluating different TLD applications and in part will have different evaluations. These bundles come from different rounds, which makes it more difficult. Two bundled TLDs should not amount to two application fees and should not be at zero cost * Allowing two TLDs to coexist, not reasonable to be free, but the goal is to make this possible at all! The exceptions process ensures that one would not be rejected and allows them to coexist. Those applications have to work on a cost recovery base, with rebate or free it would be unclear how this cost recovery would turn out or where the additional cost would apply. * Balance to incentivize and not make it costly, but can’t drive contracted parties away from wanting to be a part of this * Cost recovery principle and consideration for implementation how that looks from a financial perspective and if there is no additional fees, the it has to come from everyone else and be subsidized by other applicants would impact the program in general. Not easy to do. Promote IDNs and could have a general impact on the entire program and other applicants * Promoting IDNs and this PDP is not actually meant to promote IDNs as it is now an exceptions process to have both ASCII and diacritic one * Finishing PDP quickly no discount should be the solution and to have a fair cost recovery basis, there should not be free TLDs like in the variant case, first TLD pay full price and any additional get a discount. * Should stop comparison with EPDP, diacritics are quite different from variants. Fees also should work in a different way with a significant discount * How much does it cost in addition to the diacritic version for cost recovery? * Fees are up to ICANN based on a cost recovery basis and if they are able to provide discounts, but as a PDP we don’t know what the implementation is going to require * Discussion of wanting to have a rough estimate of the cost recovery mechanism if available. * Approach: major and important point with a lot of opinions with reasonable arguments behind them. Revisit this topic next call and prepare some slides to lay out the possible solutions: no price change, free, some reduction, up to ICANN, etc. 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

Proposed Agenda for Meeting #16
by Saewon Lee Aug. 11, 2025

Aug. 11, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #16 on Wednesday, 13 August 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #15 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

Notes from Meeting #15 on Wednesday 6 August 2025
by John Emery Aug. 6, 2025

Aug. 6, 2025

Dear LD PDP WG, Please see attached below the readout of Outcomes, Action Items, and Notes from Meeting #15<https://icann-community.atlassian.net/wiki/x/agAsFg> on Wednesday, 6 August 2025: Meeting #15 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/37198244…> [OUTCOMES] 1. Applicant must decide up front which process to follow and cannot unbundle in the middle of the process 2. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant TBD recommendations and wrote the consensus in the decision tab [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 #14 * Discussion of consensus last time looking at single application process to be further discussed today * Reviewed scope from the WG Charter to avoid user confusion and to provide clarity and certainty for potential applicants to operate the set of ASCII and diacritics * Consistent with EPDP-IDNs P1 Rec 3.4 allowing for a single application (bundle as a set) * Concern about uncertainty and to make applicants aware of exception process * Separating the application at a later stage might not be the best approach, it could also be legally problematic that suddenly one application is separated into multiple applications. * If you use the exception process then the TLDs will be handled as a bundle independently of SSR * Sarmad previously raised concern that having a bundle, but the charter clearly does not require them to be confusingly similar, only a non-negligible chance of being confusingly similar. This is well within our charter * Agreement for not having a split later in the process. * EPDP Phase 1 variant set is not made by the applicant. What would the test be to make sure that ASCII and diacritics? Similar situation for variants as the set is known upfront defined by LGR, the diacritic characters is known up front Mark’s * Edge cases brought up for SSR process for applicants in next rounds. Decisions taken are not 100% predefined. Next round exceptions process could be applied for if it was previously rejected due to SSR * Do we need a challenge process? It could be outside of the scope of our PDP * Sarmad: The motivation behind the processes are different. 1st is for strings which the applicant thinks are two different strings and managed differently. The second is a situation where the applicant considers the two strings to be the “same” or variations and they need to behave the same way. There is a different expectation inherent in the second case. Two strings representing the same thing. Option 1 and Option 2 is not just switching processes, but understanding what the two strings represent. If applicant thinks the strings are the same then the LD PDP exceptions process is correct. No motivation to switch processes * Applicant has to decide upfront if they have two labels separately, or applicant wants similar strings as a bundle. * Edge cases discussed * Possibility of dropping applied for string, in IDN-EPDP Phase 1 recommendation. If applicant submits for primary + variant, they can then withdraw the variant string, they cannot add a variant string afterwards (.Brand possible exception), there is a parallel here * Applicant has to decide upfront or decide on a path that there is some similarity in other TLD applications for community applications. If you apply as a community TLD, you have to submit all required documentation and cannot use the application change request after initial submission. Example there for requirement deciding up front how to operate the TLD. Cannot game the system by not allowing changes * Any application may be withdrawn, the question is the kind of refund depending on point in time. Should not allow to unbundle in middle of the process. * Consensus to not allow switching in the middle of the process * Edge cases should be decided once all recommendations are in place to do some test runs 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 TBD items i.Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * TBD 3.25 one can withdraw the applied for label if necessary. Sarmad discussed the variant side where a set of variants is a primary label for withdrawn vs. secondary, implications downstream. Reasonably strict dependence on having a primary label defining the set. In our case, there is an option to drop one or the other, there is no primary or secondary relationship. That is not the case with variants and this could have implications. At application time one should identify a primary (ASCII) with diacritic being variants * Base ASCII has to be the “primary” string, so one could not drop the base ASCII only diacritic versions * Discussion of edge cases and not applied for strings or diacritics then wanting to apply for it later. Asking for thinking afterwards that one was able to apply for a diacritic down the road and should not be allowed and can be picked up the next round * Only have to win the ASCII if they apply for two diacritics versions, if you apply for just one diacritic, the ASCII could still be mandatory, they could still keep diacritic one * Sarmad: variant side normally when you apply for a string and multiple variants. Needed to have a justification on why the variant is being applied for. One example where treatment of primary is slightly different from treatment of a variant. Primary string justification questions are only for variants. Two strings paired together in an exceptions process. Unless we have a primary identified and others associated, those rules can be applied. * 3.25 parts 1) withdraw variants, but not primary and not allowed to add any 2) exceptions for .Brand TLD. Do we want to have the same exception available in our process for .Brand? AGB there are special rules for .Brand to change the string down the road but with limitations for the label matches the brand * Some consensus that Brand TLDs may have similar priority rights to change applied for TLDs. 3.25 should be rewritten to our case, but meaning should be used for our case. * 7.9 Change of Control process. With blocked variants there are variants blocked by ICANN for SSR issues. Certain variants applied by the registry, but were not able to qualify for them and were rejected. Decisions taken for those variants remain, the same should hold true in our cases. * 7.14 all allocatable variants applied for has to have same rules as the main one. Do we want the same rules for our case. * Sarmad: apply for two strings bundled together could you say that one is a geographic or community TLD and the other is not? That is how to think of recommendation 7.14 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, 06 August 2025
by Devan Reed Aug. 6, 2025

Aug. 6, 2025

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

Proposed Agenda for Meeting #15
by Saewon Lee Aug. 4, 2025

Aug. 4, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #15 on Wednesday, 6 August 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #14 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

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