Dear LD PDP WG,

Thank you for the discussion during today’s meeting. You will see an additional meeting scheduled for next week on 3 December shortly in your inbox.

Please see the attached outcomes, action items, and notes from meeting #26 today. I have also included a screenshot of the whiteboard activity of the arguments and pros/cons for each of the Option 1 and Option 2 discussed.

[OUTCOMES]

• Option 1 received a majority of the WG consensus 
• Group has agreed with assessment for Charter Question 4 that there is no impact on the existing consensus policies

[ACTION ITEMS]

• All members to read the GPI and HRIA analysis for discussion next week
• LT/Staff to review PR 50 to provide some clarification in the rationale for what constitutes “necessary information” for ICANN org for specific asks
• LT/Staff to include the definition also be included in accordance with the RZ-LGR in the glossary and should be used. Look at the definition of Variants from IDN-EPDP and AGB.
• LT/Staff to update recommendations based on decision of Option 1
• Staff to send out calendar invite for 3 December WG meeting

[NOTES]

1. Welcome and SOIs
2. Recap of Meeting #25

1. Key Outcomes and Action Items

• Reviewed the slides and discussed open question of stress tests 5 and 6, outlining options 1 and 2
• Emphasis on conduct outreach from PR 50 and IG 52 may not be a good idea as it matches IDN-EPDP Phase 2 wording will be. Suggestion to leave wording as is for now as we do not want to deviate from IDN-EPDP Phase 2 as it is still under consideration by the ICANN Board.
• Group fine with wording and if there is sufficient feedback from Public Comment. ALAC is particularly concerned about this issue and may address this through Public Comment
• Query from org about specificity of “necessary information” from an implementation perspective.
• Sarmad since it is a “must” it is useful to have clarity on the minimal requirement here. 
• When they provide the information, they should also provide the LD set. 
• If LD PDP has requirement on PR 50 it would be helpful to make this more explicit
• Additional language is from last week’s discussion that outreach is made a bit stronger. The rationale will make it explicit.
• Continued discussion of IDN and Variants
• Should the definition also be included in accordance with the RZ-LGR? Also, a suggestion to take out some of the language 
• Returned to finish the discussion on Option 1 and Option 2 for LD-Variant sets on slide 9. 
• Arguments Option 1: conservative solution as we have no experience with LD or variant sets. This is a more secure solution in the beginning. Less complex, no corner cases, a simple solution. No use cases are expected and not possible for variants of LD sets. It is always possible to expand this in future policy work. Could be difficult to remove or take it back if problems do arise
• Arguments Option 2: Natural solution rather than prohibiting cases. A more complete solution that covers all possibilities. 
• Harsha shared in the chat: Modern TLD ecosystems involve cross-script confusion patterns, not just ASCII↔️diacritic. Variant Sets (especially for IDNs) and LD Sets share the same underlying problem: user confusion. Allowing them to co-exist under the same registry operator control respects existing variant principles (used for Chinese, Arabic, etc.). Option 1 creates unnecessary policy barriers without improving security.
• Option 1 would restrict but there are currently no allocatable variants that can exist with any label that is in LD Set. All variants within an LD set are all blocked now in the RZ-LGR. If the LGR will change then this will cause an issue
• From an intellectual standpoint Amadeau would prefer option 2. But he is in favor of Option 1. It is not a realistic case that such a thing would happen now under current rules for IDNs. Even if we could legislate for the future it would be a difficult wall to climb to revisit our work and delay it. This is unlikely to happen unless the RZ-LGR changes and at that point it should be revisited
• It is true that the Latin script always has to have a base ASCII; there is never an allocatable variant going to other Latin scripts. There can never be an allocatable variant of any LD set labels. The letter i is ASCII and dotless i is that only from dotless i do you have an allocatable variant, the other way is blocked. 
• Ariel: member brought up potential SSR issues, but she noted that if going with option 1 then something similar with a variant would be caught in string similarity. It is unlikely that different entities could get confusingly similar strings. Option 2 creates a lot of complexity, and there are other options in the program to prevent user confusion
• Steve: In terms of recommendations, it can recommend future work. We are discussing a theoretical scenario. You can build in a trigger mechanism that future work should be undertaken if the RZ-LGR is changed for the Latin script. If you go with option 1, you can give a recommendation that if the RZ-LGR changes then Council should consider future work. It can have future contingencies if the situation changes that you can have a solution.
• Unable to get a live example of such a case, but circling back to the RZ-LGR, if there is a future change. Then the sensibility to the stability for the RZ-LGR then that can be built into the recommendations
• Harsha prefers option 2 as option 1 is restrictive. Strasse example discussed. Option 2 has much more options available forward and backwards for option 2. 
• If/When RZ-LGR changes then an impact analysis needs to be done. The same could apply here to address the situation where changes affect the stress tests and scenarios here.
• There is a recommendation about changes to the RZ-LGR that should cover it
• Ariel: Principle from IDN-EPDP the conservatism principle. It advocates for adoption of a more cautious approach for SSR in absence of the need for a more liberal approach. She shared the language from RFC 6912 which says, “doubts should always be resolved in favor of rejecting”. This principle has been upheld by numerous studies and advice throughout the years.
• The temperature check poll favored option 1
• Suggestion to note the two options considered to get focused public comment on that specific point. 
• Saewon In the initial report the options will be described. And the consensus call will occur before the final report. If there is strong support but significant opposition there is an opportunity to submit a minority opinion to be included in the final report. 

3. Continue with Charter Topic Deliberations

a. Charter Question 4

o No issues raised on existing consensus policies 

b. GPI/HR Impact Assessment

o To be revisited next week

4. Table of Contents for Initial Report

• Staff will be drafting the initial report based on the table of contents listed in the slides
• Annex C will detail the stress tests and edge cases that the WG went through 
• Core of output is the preliminary recommendations with 8 topics and 54 Recommendations, based on the discussion today, there may be some minor adjustments

5. Next Steps

• Will resume WG meetings 3 December

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