Dear LD PDP WG,

Please see attached the Outcomes, Action Items, and Notes from Meeting #16 on Wednesday, 13 August 2025:

Meeting #16 Slides

[OUTCOMES]

1. 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 
• 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 

• EPDP-IDNs P2 TBD items

i.Filled in worksheet

• 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