Dear LD PDP WG,

Please see attached from today’s meeting:

Outcomes, Action Items, and Notes from Meeting #21 on Wednesday, 1 October 2025

[OUTCOMES]

Option 2 decided for preliminary recommendation 32 with some slight changes to be completed
Determined positions on multiple issues raised in the preliminary recommendations draft

[ACTION ITEMS]

Staff and Leadership to update Preliminary Recommendation 32
Staff and Leadership to update Preliminary Recommendation 35 and 38

[NOTES]

Welcome and SOIs
Recap of Meeting #20

Reviewed the slides and discussed how action items were resolved
Changes to IG 11 and PR 14 discussed
Updated language to PR 32 explained, do we use the adjustment or leave it as covered in the IDN-EPDP
Sarmad would the GPs automatically understand that this is ASCII/Latin diacritic gTLD label sets suggestion to clearly specify it is through this policy of the same entity.
Discussion of the meaning of full backward compatibility. Should not say to NOT make them variants, there could be a relationship in the RZ-LGR. If they are variants and they are blocked we must retain full backward compatibility to allow for allocated ASCII/LD not impacted by this.
PR 32 Discussion of exemption terminology and it could make this more readable for Public Comment and Board deliberations. Understand the intent of the WG with exemptions.
With variants we want full backward compatibility and there could be allocated variants that are blocked. Perhaps it makes sense to explain this a bit more in the rationale
Suggestion for Sarmad to keep the same language. This is something GPs and IPs need to look at on a case-by-case basis. Making things very strict or requiring backward compatibility might diverge from previous recommendations.
“A Latin Generation Panel” not “The Latin Generation Panel” suggested

3. Review of Preliminary Draft Recommendations

PR 35 does not need guidance as it is up to the registry operator to decide for itself. No need for guidance. Consistency will likely be implied given that there will likely never be a case as it is a set
Without knowing the way, the registries are using the TLDs it is problematic to force something on them without a need to force it on them
The only question here is for any change in the root or registry ICANN needs to consider the interest of the registrant, there is no need to get rid of the domains that have more users.
Add a sentence to PR35 the choice of the TLD to be kept should be done with due diligence with all parties: registrars and registrants duly considered.
Practical implications of this means that the application or contract about a set will be changed to a contract with a single TLD just as any IDN single TLD and fees would be the same as a standard single TLD.
In our context it is the same as if you were to drop a variant from a TLD set. It would be available again but would be rejected due to being visually confusingly similar.
PR 35 needs some fine-tuning based on practical consequences. But the original question of remaining TLD being defined in some way. Contrary to IDN-EPDP our TLDs are not related in the sense regarding the RZ-LGR they are basically able to exist on their own. The reason is LD is not like variants where it is subject to ASCII though they act as a set.
Possible issues for edge cases explored for dropped TLDs
There is no reason why we could have a possibility of dropping one if there are registrants. Also, there may be no case where a diacritic would NOT be confusingly similar.
What is the current policy dropping a standalone TLD? It will be sent to EBERO unless there are no registrations. Redo PR35 in that we should not also allow dropping TLDs with registrations voluntarily
Ensure these recommendations are consistent with current policies as we revise the recommendation
Reviewed the slides for understanding the 2nd level sets for Phase 2
Same entity requirements for all domains; ASCII/LD domain set.
Extensive discussion about what domains require the same entity on the 2nd level and our decision was only the exact same label will require the same entity by our rules. Only the LD PDP requires this to be the same entity. The variants are a consequence of the IDN-EPDP and not something we actively decided here.
Robust discussion of confusingly similar situations where there are not variants. Amadeu will follow up on the list.

4. Preparation for ICANN84

5. Next Steps

6. 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)