Dear LD PDP WG,

Please find attached the outcomes, action items, and notes from meeting #32 on 22 April. REMINDER: there will be no meeting on 29 April due to the CP summit in Manchester, calendar invites have been canceled, but please make sure you don’t show up to an empty zoom room.

[OUTCOMES]

Agreement with adjusted language for IG8

[ACTION ITEMS]

LD PDP WG to continuously review the Public Comment Review Tool and the proposed draft after each WG Meeting and provide input, if any.
Staff and leadership to update PR7/8 for “string” and “label” alignment and do so across all recommendations

[NOTES]

Welcome and SOI Updates
Recap of Meeting #31

a. Key Outcomes and Action Items

Reviewed the slides for consensus of PR6 and IG7. Discussed adjusted language for IG8 and there was alignment with the group of the new language.

3. Review of LD PDP Initial Report Public Comment

Reviewed the slides deferring the resolution of the diacritic set to talk more broadly about the conservatism principle. Slide 9 went through the leadership/staff initial assessment of conservatism on the recommendations.
Discussion of the table and the purpose of overall conservatism. There is no objective number to say it is more/less conservative. This is a rough overview of a holistic view of the PDP for the group to see where we think we are. There is no hard requirement for conservatism, and it is subjective.
The group has been looking closely at each recommendation, and this is just a bird’s eye view of the recommendations.
PR7 likely moved to PR8 adjustments reviewed. Query about what “explanation” is required by the applicant. Sarmad clarified that these are verified at a level of “reasonableness” for EPDP IDNs. ICANN org panel evaluates on its own in the application and is not within the scope of this group.
It was shared that this standard of reasonableness is handled in IG8
Sarmad noted that IG 8.1 might be useful to be slightly broader to also look at related scripts as well. It could be useful to say something like Latin and related scripts (Greek and others with reasonable similarity). WG did not think this needed a change.
Public Comment for PR7 reviewed for significant change required. 7.4 discussed the restriction for TLDs and there was wide agreement that it was in theory possible for an unlimited number of variants, it adds in restrictions.
PR12 PR13 discussed fees based on a cost recovery principle. Variants are a special case and ICANN was promoting these, which is why 4 were free. LD PDP goal is not to encourage people to get more LDs. It is the sole goal of creating an exception process to make it possible for applicants to have that TLD.
This is not for re-litigating the cost or fee structure, just going through the Public Comment on this topic. The scope of this PDP is narrow and not encouraging LD TLDs just creating an exception to make it possible. The conservatism principle is upheld by the recommendations unless someone wants to make them more conservative.
Concept of conservatism in the IETF context discussed. Idea of the name collision side that there are uncertainties here creating an exception that risks might arise. If there is a high-risk mechanism from NCAP that might solve part of the issue and increase conservatism.
Sarmad agreed that there is some unknown here that the process will allow potentially two strings to go into the RZ that would otherwise not be allowed because they would create user-confusion. Smaller step in the beginning and learn from it and know that it is okay then one can become more liberal. It is better to have in the RZ it is hard to delegate and take it out, that is not the right solution. That is where ICANN org is coming from in their Public Comment.
Question, by enforcing that these TLDs will resolve together, does it not solve the problem of confusion at its core? If the users confuse, it cannot be enacted; it does not meaningfully impact what type of user behavior or security behavior they would carry out. At what level are we trying to address user confusion?
Sarmad responded with an example. This is uncertain territory. Administratively tying the strings together (with the same registry and the same applicant and 2nd level the same registrant). But these strings introduce another variable that variants don’t do. That is that variant definition is consistent across all TLDs. In this case, the equivalence is applicant defined and that creates a level of inconsistency. We know that these strings will create user confusion and across different TLDs will be defined based on applicant request. That is an example of the unknowns on this topic of user confusion.
PR29 text updated and Sarmad proposed to add some conservatism and could be looked at in tandem with recommendations that talked about reasonableness for each variant to see if that creates sufficient conservatism.
The WG agreed that there should be no ceiling, but there could be an arbitrary ceiling to be more conservative. Proposal for anything after the first three would trigger a high-risk scenario

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)