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/371982416...> [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQOU...> 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/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQOU...> [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/policy...> * EPDP-IDNs P2 looks at the second level variant management Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQOU...> * 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>