Hi All,

Please find below the notes and action items from today’s meeting on 20 July 2023 at 12:00 UTC.

Best Regards,

Ariel, Steve, and Dan

Notes and Action Items - IDNs EPDP Call – 20 July 2023 

Action Items 

Action Item 1: Leadership Team to propose a suggested update / enhancement to IG 3.6 in order to align with the conservatism principle.  

Action Item 2: Leadership team to propose suggested edits to clarify Rec 3.24 and Rec 4.1 by taking into account public comment received. 

Notes

• Roll Call and SOI Updates (2 min) 
  • No updates
• Welcome and Chair Updates (5 min) 
  • Chair provided an introduction and a reminder for the GNSO Council Call at 21:00 UTC of the same day
  • Chair welcomed Daniel Gluck from ICANN staff to the support team for the IDN EPDP
• “Conservatism” Principle Discussion (up to 110 min) 
  • Chair described the principle of conservatism 
  • There was a discussion of recommendations from other policy processes that the board has not accepted, due to a variety of reasons.
    • The goal is to frame recommendations and discussions in a way that the Board will accept and not cause any knock-on effect dismissal of recommendations. 
  • Most discussions during this meeting will capture recommendation 8.1
  • Conservatism for this EPDP relates to the Security and Stability of the DNS. It should be cautious and as the principle states “doubts should always be resolved in favor of rejecting”
    • An EPDP Team member discussed his opinion on the conservatism principle and how it relates to limiting progress. It would be difficult to limit any security and stability risks as this is meant to be an innovative process. Conservatism should be balanced with other goals and values
    • Another participant discussed the ICANN Org comment on Rec 8.1 regarding the ceiling value and mentioned that the specific number may be too narrowly scoped. This value is just one part of the entire equation and there are other important aspects to consider. For example, ensuring the same entity is in control of each variant gTLD helps being conservative. There are currently domains with what could be considered “variants” of domains at the extreme level (plural and misspelled domains) but they should not be considered. The management of the complexity behind the variants of discussion for the EPDP should be considered and applied to the conservatism principle. Again, the number is too far at the forefront. Conservatism should be applied to manage risks associated with other items like the same entity principle. 

• Agreement from multiple members via chat
• A participant discussed that within this context, the policy should not address the security aspect but the usability aspect that the SSAC has discussed regarding having multiple top and second level domains where you have 16 domain names instead of the one that was originally wanted. There are certainly communities that want to automatically activate all variants for specific scripts. Registrants may not always be in control and end up with many variant domains to manage. It is a management challenge that is trying to be resolved by this process. Regarding the number of variant TLDs that can be delegated, the ccTLD is easy to manage, but the gTLD is harder to manage. The need vs want differentiation is taken away and the specific number may throw people off from registering a domain. Current recommendations have different levels that interact with each other. In some cases the structure leads to applicants that are not sure on whether to apply for the variant label TLDs to apply for them now because they are free instead of during a future round where it would cost additional money. This might not be the most conservative approach, though it may be practical. 
• There was a reply that at an industry / community level, it will be important to see the IDNs being adopted around the world. There are going to be complex operations and instructions will be complex just by the nature of registries needing to manage new variants. The policy recommendations at the time to manage risks can be implemented, but the more restrictions for IDN variant adoption, the harder it will be to get desired results of promoting IDNs.

o Another member agreed with what that reply said. Building on his point, the Market Forces will work to avoid the complexity and address the need. An applicant saying they would like variant gTLDs because they are free does not necessarily mean they will automatically get them. They may be denied because that is not a valid reason to request variant gTLDs. Their competency for managing the variant gTLDs needs to be demonstrated . The market forces can help enforce conservatism. 

§ A member replied in chat “IDNs must be handled like any other domain in order for them to have a bright future. Registry / registrars must make sure that this happens in order for IDNs to be treated similarly to other domains.”

o A participant mentioned that the focus should be changed to the manageability of the variant gTLDs by the applicant

o ccTLD constraints were discussed, including the strings being in the same language that is the official language of the country. 

§ In chat there was a reply “perhaps we can simply add an implementation guidance to ensure that IDN variant TLDs are meaningful representation of the primary applied for string”

· One participant agreed in chat, while another commented “I think that would push the implementation to something a lot more complex? Who would be adjudicating the 'meaningfulness'?”

§ The group discussed the focus on evaluation of need for variant gTLDs and verifying the ability to manage the TLDs, as well as the complexities and possible interventions for registrants. There is also the ability to make changes for a second round of TLD offerings. 

o A discussion in the chat is listed as follows:

§ “Those mnemonics would not need variants? unless the IDN variants are inherently meaningful representations of each other like simp/trad Chinese”

§ “What about other scripts?”

§ “It's not that difficult to ascertain actually, in the 2012 round, there was one question on what the TLD meant and is intended to mean... we just need to evaluate the variant against that too?... however, the 2012 round evaluated that same question”

§ “One script is already a given by the RZ-LGR, because there are no (or only in exceptional cases) cross script allocatable variants”

§ “I think we were told that only Arabic and Chinese has allocatable variants”

§ “For existing gTLDs, only these two scripts have allocatable variants according to RZ-LGR. But for future applicants, potentially 5 additional scripts may have variant applications”

• Recommendations 8.1, 3.11, 3.12, and 3.14 are non-conservative recommendations. 
  • 8.1 due to a lack of ceiling value
  • 3.11 due to having the same base application fees for four variants 
  • 3.12 due to additional variant labels may incurring additional fees
  • 3.14 due to waiving the base application fee for existing ROs 
• The Chair asked ICANN Org to walk the participants through four potential paths forward as a prompt to brainstorm within the group to address the conservatism principle
  • Path 1 would keep rec 8.1 and make the other recommendations moderately conservative (lower the upper limit of free allocatable variant labels)
  • Path 2 would make rec 8.1 slightly conservative, 3.11 as is, and then 3.12 and 3.14 slightly conservative. (Setting the ceiling value of 4 and allowing exceptions with defined review periods, and changing “may to must” regarding additional fees for 3.12 and 3.14)
  • Path 3 would make all four recommendations moderately conservative (For 8.1, set ceiling value below 4, and allow exceptions. For the other three recs, change the upper limit to ceiling values and change “may to must” regarding additional fees)
  • Path 4 would make all four recommendations highly conservative (For 8.1 set the ceiling value below 4 with no exceptions. Remove Rec 3.12. Remove provisions in 3.14 regarding applying the hard 4 cap to existing ROs)

• From the Chair in chat “I acknowledge that on the back of the conversation we’ve just had, that ‘no change’ to our recommendations is what I’m hearing. However, I’d still like to run through these options for consideration. The review would be built in as a ‘must’ to review whether the ceiling value is warranted”

• A reply in chat said, “I think we better align with ccTLDs rather than make arbitrary limits... or else it would be a divergence from a policy standpoint?”
• Additional discussion on this mentioned that aligning with the ccTLD would be problematic due to the nature of ccTLDs having the natural script / language barriers. One response could be to limit four free variant labels to two. This would cover Chinese and Latin. 
• A third reply in chat said “but for such vanity names, there could still be meaningful representation of the vanity name, or else the IDN variant TLD should not be allocated? because users would not identify them as "same"”
• The Vice Chair discussed other recommendations and implementation guidelines and asked whether the group would be interested in discussing the further changing IG 3.6 to a recommendation. 
  • This was agreed to by multiple members..
• Following up on the prior suggestion of lowering the number of free allocatable variant labels, the Chair asked the Team for their opinions. There was push back from different members, for reasons including disadvantages for Arabic, with no additional support for the idea.
• The EPDP Team preliminarily agreed on no change to Rec 8.1, 3.11, 3.12, and 3.14, but planned to revisit IG 3.6 in conjunction with Rec 3.5 and consider elevating 3.6 to a recommendation. 

Action Item: Leadership Team to propose suggested update / enhancement to IG 3.6 in order to align with the conservatism principle. 

• Continue with Public Comment Review (Start at IG 3.23) (time-permitting)
  • Ariel Liang, ICANN Org, walked through some public comments on other recommendations.
    • 3.23 - No Comment
    • 3.24 

• A participant mentioned some of the limitations of the tools available and the ability for reviews to take place in future rounds.

• The chair asked if this was workable at all?
  • ICANN Org replied that while the first part of the preliminary recommendation makes sense, the second part seems to imply that ICANN org must monitor potential updates to the RZ-LGR to check whether a disqualified string can be applied-for later on. The question is whether a disqualified string will stay in limbo, or the applicant has to submit a new application when such a string becomes valid / allocatable after a RZ-LGR update
  • The Vice Chair replied that “ If the RZ-LGR changes, then the output of the tool would also change, wouldn't it?”

• A member replied, “I don't think that is our intention that an application would stay in limbo?”
• A participant mentioned that his recollection is they do not anticipate ongoing monitoring / assistance being included. 
• Finally, there was discussion on the process and the potential for an irrational actor applying for a script that is not available. After thinking it over, there may be a need for the applicant to state that they know the string is invalid and provide a reason they applied for it. 
• 4.1 
  • Comments on this recommendation were discussed, including potential revisions to the wording in the parenthesis in the first half of the preliminary recommendation.
    • A comment in chat said “I don't think we lose the meaning of our recommendations if we remove the language in the brackets” 
  • A participant asked about the scope of the comparison in the last items. The String Similarity Review panel may find strings that are one or two characters to be confusingly similar to a two-character ASCII string or its variant. The phrase in the bracket may be too limiting and may forbid the panel from identifying such confusingly similar cases. 
  • A member commented that outcomes of the String Similarity Review are the most important; the process of getting there may be up to the String Similarity Review Panel to decide . 
• AOB (3 min)
  • The Chair Adjourned the meeting.

Action Item: Leadership team to propose suggested edits to clarify Rec 3.24 and Rec 4.1 by taking into account public comment received. 

Dan Gluck