Dear LD PDP WG,

Please see attached below the readout of Outcomes, Action Items, and Notes from Meeting #15 on Wednesday, 6 August 2025:

Meeting #15 Slides

[OUTCOMES]

1. Applicant must decide up front which process to follow and cannot unbundle in the middle of the process
2. Filled in Spreadsheet of relevant TBD recommendations and wrote the consensus in the decision tab

[ACTION ITEMS]

• WG to review upcoming TBD items in the worksheet 

[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 

• EPDP-IDNs P2 TBD items

i.Filled in worksheet

• 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