Dear all,

Please find below the notes and action items from today’s meeting on Thursday, 1 September 2022 at 13:30 UTC.

Kind regards,

Ariel, Steve, and Emily

Notes and Action Items - IDNs EPDP Call – 1 September 2022

Action Items

Action Item 1: Leadership team to propose recommendation language to bring back to the EPDP Team for Charter Question E5 (Part 2).

Action Item 2: ALAC representatives to propose a path forward on Rationale for Recommendation 2.6.

Notes

Welcome & Chair Updates

• Update on data collection to support EPDP Team work on String Similarity: Leadership team has been considered how data could support the EPDP Team’s consideration of the hybrid model presented by the small group over the last few weeks.
• Leadership team is working on gathering information about 20-30 strings from the 2012 round to see what would have happened if blocked variants were included in the String Similarity Review. This will help the EPDP Team assess the risk of variants when going through String Similarity Review and understand the costs, benefits, and operational impacts.
• While the focus of the EPDP Team is on policy recommendations, it would help the group to have some understanding of the operational impacts.
• We are potentially creating process for edge cases. Leadership team is exploring whether the ICANN org risk management function might be able assist with providing tools to support evaluating the risks in the context of different models.
• RySG is also having internal discussions on this topic. Procedure to develop RZ-LGR did not have as a goal identifying confusable similarity. The primary goal was to identify variants that may be allocatable. Let’s not consider that the RZ-LGR as the way to identify confusable similarity but an element of that analysis.
• Comment that we have to keep the door open for those who feel that they have rights or there is potential confusion with their string to engage in challenge process.
• Comment that we need to take care that this not a reservation system. You shouldn’t be able to prevent someone from applying for a string because there is a string that you want to apply for in the future.
• The EPDP Team will meet next week but not the following week. There will be two sessions in KL. Details about KL sessions will follow.

Strings ineligible for delegation

• Slide 4 – Charter Question E5 (Part 2): Should the strings ineligible for delegation be updated to include any possible variant labels?
• Slide 5 – Strings Ineligible for Delegation – chart showing strings in different categories: IOC, Red Cross & Red Crescent, IGOs, and INGOs
• See also https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IOC & https://community.icann.org/x/MpLRAw
• Clarification that this refers to the top level. At the second level, these strings have been identified and we can expect the same approach at the top level.
• Clarification about difference DNS Label 1 and DNS Label 2: DNS Label 2 is only applicable at the second level.
• Is the expectation that the variants of the IDNs on this list would also be blocked?
• Depending on the script, some might have allocatable variants, as demonstrated on the following slides, but many will be blocked.
• Slide 6 – Examples – randomly selected from list of strings ineligible for delegation.
• In response to comments that the Cyrillic example should have variants, clarification that the mixed scripts are filtered out of the results for this table.
• Suggestion to add disclaimer that screening out mix-script labels is not normative but an option.
• Staff comment that, for the final Latin example the number should actually be lower than the number presented on the slide. The number should be 2,592 blocked variant labels.
• Slide 7 – How to Address Variants of Strings Ineligible for Delegation – two options:
  • Option 1: Keep the list of strings ineligible for delegation intact and NOT to update it to include their variants
  • Option 2: Keep the list of strings ineligible for delegation intact and NOT to update it to include their variants. Prevent applications for all variants of the protected strings. Variants can only be applied for by the relevant organizations AND as part of a 'set' that includes the primary string on the list.
• Slide 8 – Option 1 Rationale
• Slide 9 – Option 2 Rationale
• Slide 10 – Considerations – factors the EPDP Team takes into account may include risk analysis, operational impact, and costs vs. benefits.
• Comment that these are good questions to ask. With respect to this question: “How would such measure be perceived, taking into account the careful deliberations of IGO PDP that took years to complete?” --
  • If we take this as a baseline goal to honor the IGO PDP recommendations, we want to be careful not use those recommendations as a vehicle to extend the privileges already given and not interfere with those. Perhaps the solution is do nothing and put the burden on the IGO organization to object where they believe it is appropriate to do so on the basis of confusing similarity. This perspective seems to lean towards option 1.
• Question about whether the lists are meant only to protect the label or to reserve the label so that the entity will be able to use it themselves.
• If the latter, we would need to block variants as well. If someone registers the variant, it prevents an entity itself from getting the string.
• Clarification that they are reserved, but there is an exception procedure where the “owner” of the string can apply for it.
• Do the “owners” keep that right for all time? If so, we have to block the variants. Otherwise, we may be taking away that right. This perspective leans towards option 2.
• According to the RZ-LGR all variant labels in a set must be allocated to the same entity. If we allow a variant label to be allocated to a third party, the NGO or INGO will not be able to apply for the original label. If we allow that, it will eventually break the variant set.
• The problem is not whether the applied for string is confusable with the string ineligible for delegation. It is that if the variant is delegated, the string “owned” by the IGO/INGO will not be available to that entity for delegation.
• At the time the list was created, the RZ-LGR did not exist and was not factored in. Because the list was developed by a rigorous process, by adding the variants, there is concern that we are creating additional rights. The strings already protected are protected based on treaties and existing lists.  The variants have not been pulled from an existing list. While acknowledging the problem that if a variant is applied for by a third party, you are taking away the ability for the entity to get the primary if it’s not picked up in an objection process.
• Is there a middle ground without adding to the list but also providing some protection for the variants?
• It could be the responsibility of the NGO/INGO itself to be responsible for monitoring when a variant is applied for, but given the length of the list of variants this could be a challenge.
• The way this would be implemented in the tool, it wouldn’t enumerate all possible variant strings. The tool could include a list of strings ineligible for delegation. When someone types in a label, they can see that it is variant of one of these labels.
• Suggestion to keep the list as it, but for each string we compare each applied for string and its variants with this list.
• Important that we are respectful of other policy recommendations from other groups. How will it be perceived if an application is blocked due to a variant relationship and there is a perception that rights have been extended as a part of this process?
• It was noted that IGOs were given the opportunity to determine the names to be on that list and have reserved (at least at the second level) different versions of their name, maybe variants, maybe not
• From one perspective, whether they considered variants or not, it is not really important. ICANN granted them the right to reserve their (main) label. In order to uphold that right, we need to block all variants.
• The primary focus of the IGO recommendations is preventative – to prevent the use of these strings by other entities. The exception procedure is secondary.
• At the second level, rules regarding INGOs are here: https://www.icann.org/resources/pages/igo-ingo-protection-policy-2020-02-18-en
• Summary: Group appears to be leaning towards option 2.

Action Item 1: Leadership team to propose recommendation language to bring back to the EPDP Team for Charter Question E5 (Part 2).

• Staff comment that the options could include additional color. Option 1 could still include protections under Legal Rights objections, GAC Advice, GAC Early Warning, etc. Option 2 would fully block the variants. Both could potentially offer protections, but to a different degree.

Second reading of Group 2 outcomes

• Group 2 outcomes: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit
• See above Google Doc for comments and suggested edits from RySG and response from ALAC regarding Rationale for Recommendation 2.6.
• RySG wants to emphasize that the rationale should not expand on the recommendation itself. The recommendation is about technical and operational competence, the rationale should not make an editorial note on what that means. While acknowledging the overarching goal that ALAC is putting forward, this recommendation and rationale is not the right place to reflect it. ROs don’t manage or moderate content, disputing the idea that user experience is part of operational aspects.
• ALAC perspective is that there is flexibility in the exact language and where it belongs. The idea ALAC wants to capture is that there is a continuous chain between registry, registrar, reseller, and registrant. ALAC will suggest way to close the gap between the different perspectives.
• ALAC may want to expand on what is meant by consistent user experience. Is the idea that if a user goes to a domain under the primary label and one under the variant that they will see the same thing? This appears to go beyond what an RO can do. With this recommendation we are trying to set up the application process and what the potential applicant can define and expect in the process and be evaluated on. The focus is technical and operational in nature.

Action Item 2: ALAC representatives to propose a path forward on Rationale for Recommendation 2.6.