[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #57 - 10 November 2022

[Emily Barabas]

Dear all,

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

Kind regards,

Ariel, Steve, and Emily


Notes and Action Items - IDNs EPDP Call – 10 November 2022

Action Items

Action Item 1: Staff to find out if there are documents that the ccPDP can share ahead of the 29 November joint call.
Action Item 2: Leadership team to develop some examples of the consequences of the different options for Community and Legal Rights Objections processes.
Action Item 3: Leadership team to propose a path forward on E6 based on the conclusions of today’s discussion.

Notes

Welcome and Chair Updates

  *   The ccPDP4 requested a joint call to discuss how the two groups are addressing the issue of string similarity. The meeting will take place on Tuesday, 29 November at 14:00-15:30 UTC. An agenda will be shared soon.
  *   The ccPDP4 focus seems to be on the evaluation panel, procedures, and criteria. They do not appear to have addressed the role of variants ye.
  *   The EPDP Team will share the status of deliberations on EPDP Team recommendations.

Action Item 1: Staff to find out if there are documents that the ccPDP can share ahead of the 29 November joint call.


  *   Leadership suggests going ahead with meetings preliminarily scheduled for 1 and 22 December to help ensure that the group keeps making progress. Those who need to miss the calls can catch up with recording.
  *   Farrell as GNSO Council Liaison has submitted the Project Change Request for this group to the Council for its consideration at the November Council meeting.
  *   Paul McGrady asked a question on the Council mailing list regarding dependencies between this group’s work and the implementation of SubPro. The leadership team will discuss a possible response during its meeting later today. It is important to acknowledge that there are still unknowns about the timeline of SubPro implementation.

Continue Discussion of Charter Question E2 – Options for Legal Rights and Community Objections

  *   Slide 4 – Legal Rights Objection Recommendation – Option 1 and 2
  *   Jeff has an action item from the previous call to write up a proposal for a specific exception process for the Legal Rights and Community Objections. Under the proposal, the applicant will be given an opportunity to show why there is not a risk of misconnection. He will be sharing this soon.
  *   Comment: A trademark owner should not be prevented from applying for a mark unless it is actually a variant of a string that has been allocated.
  *   Comment: If we are moving forward with the hybrid model for string similiarity, the EPDP needs go with option 2 for the Legal Rights Objection. If the objection is successful, it may be the case that the objected-against primary string should be able to be delegated, but perhaps the allocated variant may not.
  *   Question: Would this impact our recommendation on the use of the RZ-LGR?
  *   Response: No, because these processes are about similar strings and not exact matches.
  *   Agreement that it would be useful for staff to draw up specific use cases describing the consequences of each option in a practical way.
  *   Comment: The question at hand should not be about who can file an objection, but about the scenarios in which an objector can be successful if they file an objection.
  *   Slide 6 – Community Objection Recommendation – Option 1 and 2
  *   Comment: For the community objection, it seems that we will need to start with Option 2, taking into account Jeff’s proposal, which would factor in which strings are potentially removed from the list of those impacted by the outcome of the objection.
  *   Comment: If we are moving forward with the hybrid model for string similarity review, then we need to use option 2 for Community Objections, as well. An objector should be able to object if an application could potentially block them from applying for their string in the future.
  *   Comment: RySG reiterates its position that some blocked variants are valid labels but many are not well formed labels and will never be delegated. These should not be considered in the case that blocked variants are included in the model more generally.
  *   Question: How difficult is it to tell is blocked variants are not well formed?
  *   Response: These can be determined computationally.

Action Item 2: Leadership team to develop some examples of the consequences of the different options for Community and Legal Rights Objections processes.


  *   ICANN org will soon be providing input on the WG’s initial work on the hybrid model. This will be taken into account in further deliberations of the EPDP Team.


Continue Discussion of Charter Question E6

  *   Chair proposal: there is no good reason to allow a two-letter gTLD label in the Latin script, especially given sensitivities with the cc community.

  *   If such applications were received, it would be considered unlikely that they would have passed the String Similarity Review as they would likely be considered similar to two-character ASCII strings.
  *   Slide 9 – Charter Question E6

  *   Slide 10 – ccTLD Context
  *   Additional information: ISO-3166 is maintained by a maintenance agency which can assign unassigned two-letter codes to new countries and territories. That is outside of ICANN. Two-letter combinations are not available because they could be assigned in the future.
  *   Slide 11 – What happened in the 2012 round?
  *   Slide 12 – Analyze the Question
  *   Clarification: We can divide the Latin set of characters into 4 categories:
     *   ASCII
     *   Plain characters – these don’t have a diacritic, but are outside of the core A-Z characters, for example the German sharp s.
     *   Decorated characters – plain characters plus a diacritic, identified in RZ-LGR as a variant of a base character.
     *   Decorated characters that are not identified as a variant of a base character.
  *   As a reminder, any application for a two-character string regardless of script will go through a process evaluating the visual similarity to a two-character ASCII combination.
  *   Comment: We should not just look at the Latin script or create special rules for the Latin script. If we disallow 2-letter TLDs for Latin, in general, this should also be the case for Cyrillic and maybe some other scripts. Do not disallow, but whenever applied-for strings are confusingly similar to a 2-character ASCII label, they will be rejected. This will be true for all scripts that have characters that are similar shapes to ASCII.
  *   Question: What would be the test for confusing similarity. Is this something we should include in implementation guidance?
  *   Slide 13 -- Drawing on the analysis, should a recommendation be developed to explicitly prohibit an application for any two-letter gTLD string in the Latin script?
  *   Comment: No, unless the recommendation is extended to other scripts too, for example all alphabetic scripts. If you extend to all scripts, in the case of certain scripts, only a subset of characters will be potentially confusingly similar to ASCII characters. Rather than restricting the whole script, it makes more sense to allow the string similarity review to take care of concerns about confusion.
  *   Comment: Applying rules uniformly across scripts is better than doing it case by case. If you can’t make a blanket rule, then the best approach is to focus on the confusing similarity standard.
  *   Slide 14 – Jeff’s Proposal: Adopt a similar recommendation as SubPro Recommendation 25.4 for Single Characters – “Recommendation 25.4: Single character TLDs may be allowed for limited script/language combinations where a character is an ideograph (or ideogram) and do not introduce confusion risks that rise above commonplace similarities, consistent with SSAC171 and Joint ccNSO-GNSO IDN Workgroup (JIG) reports.”
  *   Question: Would it be necessary to list scripts for a two-character recommendation? In the single character case, the recommendation says that they need to be ideographic. There are different kinds of scripts. If you made a recommendation like 25.4, would you limit to specific scripts or types of scripts?
  *   As a reminder, the string similarity review would already address some of the examples on slide 14.
  *   Comment: The single character analogy is not useful. Single characters have little context, so it is appropriate to take a conservative approach. With two character strings there are more things to consider. Agreement that we shouldn’t have a policy focused on a single script. The simplest approach is to go by the confusing similarity process.
  *   Staff observation: The benefit of Jeff’s approach is greater clarity for the applicant about what they can and can’t apply for. But even if the proposal is not used, the string similarity process will catch cases of similarity. It just means that some applicants will take the time and resources to apply and later find out that the application can’t proceed.
  *   Question: Is there a difference between a two letter and a two character gTLD string?
  *   Response: Character means symbol. It is a broader term that encompasses alphabetic and non-alphabetic scripts. Letters only apply to alphabetic script. All letters are characters but not all character strings. See also: https://unicode.org/glossary/#character
  *   The existing string similarity standard in the 2012 round is more expansive than the scripts on slide 14, and applies to combinations in all scripts checked against confusing similarity with two-character ASCII combinations. The standard of review was upheld by SubPro. The question is whether that standard should be supplemented with a prohibition on certain strings or whether the using the string similarity process alone is still appropriate.
  *   From the AGB: Review of 2-character IDN strings — In addition to the above reviews, an applied-for gTLD string that is a 2-character IDN string is reviewed by the String Similarity Panel for visual similarity to:

a) Any one-character label (in any script), and

b) Any possible two-character ASCII combination.

An applied-for gTLD string that is found to be too similar to a) or b) above will not pass this review.

  *   SubPro Final Report - Affirmation 24.2: Subject to the recommendations below, the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string. According to Section 2.2.1 of the 2012 Applicant Guidebook, “similar” means “strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.” In the 2012 round, the String Similarity Panel was tasked with identifying “visual string similarities that would create a probability of user confusion.”155 The Working Group affirms the visual standard for determining similarity with the updates included in the recommendations below.
  *   Question: Should this group revisit what happened in the IDN Fast Track process in relation .ευ?
  *   Response: SubPro looked at this and because the cc process is different it is not easy to apply lessons from this case to the gTLD context.
  *   Conclusion: The possibility of confusion will be picked up in the string similarity review. We may not need a recommendation beyond what already exists in SubPro.

Action Item 3: Leadership team to propose a path forward on E6 based on the conclusions of today’s discussion.

AOB

  *   Donna has left GoDaddy but intends to continue serving as Chair of the EPDP.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20221110/dd07ba4e/attachment-0001.html>