Dear LD PDP WG,

Please find the attached outcomes, action items, and notes from Meeting #25:

[OUTCOMES]

Between the choices option 1 and option 2 consensus began to emerge on option 1, but the discussion will continue next week.

[ACTION ITEMS]

LT/Staff to revisit IG 52 and adjust that language – conduct outreach – to put some stronger emphasis on providing information to registrants

[NOTES]

Welcome and SOIs
Recap of Meeting #24

a. Key Outcomes and Action Items

Reviewed the slides and discussed meeting #24 updates to the documents based on action items
Rec #45 updates discussed how a registrant may not be aware of LD PDP policies. Registrars do not have to support LD sets as it is up to them and their business models. The ICANN outreach recommendation encapsulates this.
EPDP two phases is new for variants and Latin diacritics. A lot of new things in the ICANN to-do list should be strengthened to be passed on to the registrants. Rec 50 encapsulates this along with IG 52.
Where best to locate this outside of the preliminary recommendations is the open question.
A collection of recommendations that disincentivize auto activation like PR 52 and the fee structure for the domain names. In addition to the outreach there are other measures that would likely guard against automatic domain registration.
Case Studies #5 and #6 combined in combining LD sets and variant sets. This should be consistent between the two and understand which policies apply.
Two options to solve these cases outlined on slide 10.
When we are putting a policy that restricts registries/registrars we need to say why there is a prohibition. What is wrong with option 1?
Suggestion to go back to the principle of TLD and their variants. Any domain and their variants have RZ-LGR, if you look into both cases, if we go for option 2 then we do not follow that principle. Better to go for option 1 even if it has some restrictions.
Implications of option 1 and option 2 outlined in the slides then we will discuss the pros and cons of each.
Clarification for having variant TLDs you need to define a primary label. IDN-EPDP you start with one primary label then you can activate variants for that label.
We are working to find out what TLDs a registry would be able to activate
Sarmad: added to slide 12 example. One of the underlying properties of variants is they are a transitive set. That is something around which the structure of variants at the top and 2nd level come together. In this case we are seeing that we can get into relationships as we have this ad hoc LD TLD in the mix in addition to variants we can get into potentially problematic variant relationships. That transitive relationship is inherently not there with LD TLDs in the variant mix. It is not clear what is the relationship between these examples.
When you start with LD set you have all TLDs are related to each other by the LD PDP if you add variants to one of the LD TLDs then if you allow this then you have multiple variants in this set that are not variants of each other nor an LD set. Due to a combination of LD and variants they would end up in the same set of TLDs. We would then need a new definition of this LD TLD set.
Continued in the slides for which recommendations would need to be re-considered and re-worked for option 2.
Pitinan noted that an ASCII TLD would be affected and would have to go into more detail what would happen in a multi-set with certain TLDs removed or retained.
Alan raised a point on recommendation 39 suggesting that we use the phrase IDN variants so it is not mistaken for Latin Diacritics, once the combination is allowed.
Continued in the slides to demonstrate the number of recommendations that would need to be adjusted if option 2
Alan in chat: “My concern is that people might misunderstand the term "variant" to think it refers to one half of a n ascii/latin diacritic set. Using the phrase "IDN variant" instead of just the word "variant" reduces the likelihood of this mistake.”
Michael noted that this should be adjusted in the recommendations
Option 1 is less work, Option 2 might be more natural by allowing this and it is complicated with lots of side effects and Michael opened the discussion.
The problems with option 2 are SSR, contractual, usability, all those areas are impacted by option 2. This would be combining multiple primaries, variants, and LD sets.
Sarmad: Added that at this time one would really need to get into the analysis to figure out the answer of what is impacted. There are huge implications of option 2 some of which are more complicated and there could be larger implications for SSR and a deeper dive into these.
Steve: Highlighted concern from ICANN org that policy development michael demonstrated that option 2 represents tons of complexity both for the recommendations and an enormous amount of complexity for implementation. This means time and confusion for applicants and registrants. The issue about end-user confusion is compounded by the layers of complexity. There are impacts in adding complex things to recommendations. Policy development is not absolute. If this additional layer. You could proceed with option 1 now and future policy development could tackle option 2. Core principles of WG is that it is an exceptions procedure and a conservative approach is advisable. Option 2 is raising alarm bells for staff based on our experience.
Ariel: aligned with staff on this issue because thinking through all the possible options and then how to explain that to implementation or to the Board of what this recommendation means could be very complex. If the group does go with option 1 the limitation restriction is much less than RZ-LGR. For Diacritics it would be more lenient in that interpretation, there could be string proliferation risk could impact the DNS security and stability. The complexity of this would be difficult to explain to all impacted parties.
Option 2 is principally true, but we cannot make rules for major unlikely hypotheticals. These are decisions we have made for certain reasons and there is a way to describe what we want for complex sets. It should not be unnecessarily complex for the sake of it so in favor of option 1.
Chances of having a LD set and also a variant set would be highly unlikely
All the recommendations impacted by option 2 wondering if the same entity principle still exists, the integrity of the set. It should likely still remain in tact, but could requires some adjustments to recommendations to ensure this
Sarmad: LD goes from one variant set to another variant set because of relationship between ASCII and LD each has their own variant sets and could proliferate variant sets.
Consensus seemed to emerge in favor of option 1, but discussion would be considered next week.

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)