Dear LD PDP WG,

Please find the attached outcomes, action items, and notes from the LD PDP discussions at ICANN85.

[OUTCOMES]

WG agreed with Inconsistencies 1 and 3 to be updated by staff
Majority in favor of recommendation 7 to utilize the EPDP-IDNs of 3.5.2 Explanation of how the primary and variant labels are considered the same”
Updated Public Comment Review Tool

[ACTION ITEMS]

Staff to update Public Comment Review tool to be updated by staff and then a draft will be circulated to the WG.
Follow up with Ariel on IG 11 query and staff to add a word or “general” to intent.
Staff to Update language based on consensus discussed in WG for each recommendation
WG to postpone and revisit discussion of Preliminary Recommendation 50
WG to follow up with Ariel on PR 6 if ICANN org comment becomes a substantive comment given the requirement in PR 1 and PR 6
All WG members to review the Public Comment Review tool with special emphasis on PR 1 and PR 39: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4BE5Xr9crE/edit?usp=sharing

[NOTES]

Welcome and SOI Updates

Seb updated his SOI from GoDaddy to Unstoppable Domains and noted he is a part of this PDP.

2. Overview of LD PDP Initial Report Public Comment

Saewon went through the slides with an overview of the Public Comment.
Shared the Public Comment Review Tool: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4BE5Xr9crE/edit?usp=sharing
Public Comment summary report will be available here shortly: https://www.icann.org/en/public-comment/proceeding/latin-script-diacritics-pdp-initial-report-12-01-2026
PR 1 and PR 39 may need to be addressed as it concerns the scope of work.
Key Principles were mentioned during ICANN85 sessions reviewing of the Public comment submissions was done through the slides, but going forward the tool will be the primary source
GOAL: not to revisit or reset agreements unless it is crucial to keep the key principles in mind as on slides 9
Mark D. emphasized the openness of the PDP to reach consensus. Managed to get consensus pretty well constrained and that is a win. Some public comments were substantive, and will not rehash, but reassert the position.
Mark: There is a substantial impact from ICANN org and there was a seat here during the PDP. ICANN org was able to participate thoroughly. ICANN org is just another person giving feedback to the PDP and it will be addressed in the same way throughout the process.
Welcomed Christian Dawson as the new liaison for the GNSO Council given his substantial expertise in these areas
ICANN org input could be slightly different given the core issues and some of those discussions may need to be had with the Board as well through the liaison

3. Start Review of LD PDP Initial Report Public Comment

Slides 10-11 discussed the issue of consistency for the style of writing between IDNs and LD to be precise unless there is a reason to differ from the original language.
Floor opened up for discussion for the consistency issue from org. Michael asked if it is necessarily the same. If the intention and meaning is the same even if there are small differences that are required to make it the same
Consistency Issue 1 is straightforward and can be done. Consistency issue 3 raised in terms of PR 35 and 36 differed largely from EPDP-IDNs so here there should be a language different from and which part is different within the recommendation language
Sarmad added in doing implementation analysis it is helpful to understand if the recommendation is the same as or consistent with IDN-EPDP, then you can easily look at analysis for IDNs to inherit it. If it is different, it requires an independent analysis with some overlap and some difference, look how it was analyzed in IDNs.
Inconsistencies in 1 and 3 are quite clear.
Flagged the issue that there is a lot of dependence on EPDP-IDNs, consistent with is that it is dependence heavy. What happens if there is EPDP changes, we might want to consider how that might be impacted
Public Comment Review tool to be updated by staff and then a draft will be circulated to the WG
Inconsistency 2 needs to be gone through one-by-one on how to label each from the Public Comment Review Tool
Recommendation 7: ICANN org noted that the LD PDP has differed from the original language
Actual words used should have the same meaning. This is an exceptions process to prevent user confusion, then it is reasonable to justify why you want to handle these TLDs jointly, this is not too much as a requirement
The recommendations from this PDP and IDNs should be consistent. If this PDP has used some of the language then it should be consistent
Sarmad: The motivation for EPDP IDN’s for rec 7 was the general aim was to minimize the number of variants delegated and that should come from clear need rather than just a desire. IDN WG put in these criteria to get details on why this is needed and an independent panel would evaluate the applicant based upon four questions. In the case of LD PDP is missing a few elements. It is missing one criterion it may be consistent but not the same. Whether that particular condition should be considered by the WG and handed back or whether that is okay.
Diacritics are often not variants of the same word. Case is similar to variants in that sense and are defined in the LGR, whether two labels/words being variants have the same meaning may depend on the language/word itself. The same with diacritics.
Rec 7, should the WG introduce “3.5.2 Explanation of how the primary and variant labels are considered the same” that was missed? Or should this be changed and not ask the same questions and if so, why and what other questions would the WG want to ask?
Idea is to have TLDs to essentially be the same, reiterating the same entity principle and this should be a requirement here.
Does the WG want to allow the TLD to coexist with different meanings or not the intention of the PDP to allow this?
Applicants should prove that these labels are used interchangeably. With the current situation the applicant would not be allowed to proceed.
Does it matter if they mean the same thing, because many have already omitted the diacritic because it has been used in the current TLD form?
Same means interchangeable not necessarily on meaning
Sarmad: variants are two dispositions exist and be blocked or could be allocated. Suggestion from the technical community, allocatable delegations should be minimized. Blocked should be maximized as that is motivated by security concerns and end user confusion. For a small number some may be needed by the community as they are used interchangeably.
Pitinam: SAME means perceived as the same by the community. Does not literally mean the same in meaning. Useful to explain why these are perceived by the community, the meaning is not the same.
There is a narrow scope of this PDP and should stick to well-established community precedents
Summary: most people agree to the requirement from IDN-EPDP re-introduced, one skeptical.
Steve: IG 8 for EPDP-IDNs and the criterion should be standard of general “reasonableness” to make the process not overly onerous, but avoiding proliferation.
- IG8: 8.2 The evaluation panel should apply criteria based on a general standard of reasonableness and the criteria must be established during implementation;
IG 11 also had the consistency issue with EPDP-IDNs. Wanted the WG to confirm that additional policy work would not be needed and it could be implemented directed
- 1) Deal with consistency language
- 2) Proposed outputs on additional tests
Intention is additional analysis in addition to the variants needs to be done but it could be done differently in the case of Latin Diacritics
It appears to be an additional step, but we want it to be the same, but for the variants there is a certain mechanism that will be taken by ICANN and that should be for LD PDP as well. There is not a difference in intent.

WORKING SESSION 2

Began with slides looking at PR 29. The intention of our recommendation is the same as was with IDN-EPDP, but we changed some wording. Discussion of “in some instances material differences”
Basically the comment from ICANN org is referring to all the linked outputs. It does not only refer to this one. There are additional sentences that LD PDP has added for this recommendation and taken out the RZ-LGR. There is inconsistency in the language but how it applies to our PDP
Staff to adjust wording on the background
IG 41 difference in automatic activation portion that has been taken out for our PDP use. ICANN org noted that this is non-substantive. It is nice to have for org to see where there are changes, but here there is no real change so it should be left as is.
IG 41 Change to AND to be consistent
PR 50 has a substantive issue, with respect to what “necessary information” entails. WG should clarify what is being requested and what this interpretation encompasses.
The reason this was changed was there was a request by the group to be clearer about this outreach that ICANN should do. How much clearer do we need to be? Should the WG go back to the original language of EPDP-IDNs or else provide a bit more detail about what the WG wants to do.
Suggestion that the WG does not fall back on the EPDP discussion by default.
Goal is to not imply consistent with when sometimes the recommendation takes a break.
The WG dedicated a time to conducting outreach to necessary information
PR 51: clarify why the initial source domain name was omitted? This is not a standalone decision and is defined in multiple points. Is there any clarity as to what is omission as substantive or is it clerical? Or is it because of the source-domain logic as to why this omission has happened? This appears to be an oversight and should be corrected
PR 53: not inconsistent even though wording is not the same. We are just clarifying for the scope for our PDP.
Non-substantive comments could change wording, as the intention is the same.
Shift from consistency to a new topic on slides 12: PR 4 org was asking for clarity on wording change on “immediate next round”
Saewon noted that Kyionna Blaylock made a number of inputs as an individual public comment on many recommendations and did not provide any rationale or proposed changes to it. Michael agreed that further input would be needed, but without additional context, it would be noted but cannot be acted upon.
Language could be cleared up as immediate next round perhaps it was clearer for IDN-EPDP would be necessary for the Next Round, and it could not be started without IDN-EPDP, but it may not make sense for the LD PDP.
Brief discussion on the next round and where LD PDP fits into that, but it may be out of scope for this PDP.
Clarify which round is meant at the time when the policy becomes adopted. It is obvious when the policy is active. Keep the language for now, add footnote, out of scope to define which round this refers to but will be visible when it gets adopted.
PR 6: might want to think about whether the WG intends to allow the withdrawal of the ASCII label in case there is just a single diacritic label left. ICANN org wanted to clarify if this is indeed the case
If there is just one diacritic TLD remaining you could withdraw the ASCII. Since that is the case ICANN org may want to make this a substantial comment.
IG 8: ICANN org’s wording is fine on the non-substantive issue

All the best,

John R. Emery, Ph.D.

Policy Development Support Senior Specialist

Generic Names Supporting Organization (GNSO)

Internet Corporation for Assigned Names and Numbers (ICANN)