[Gnso-epdp-idn-team] Notes - IDNs EPDP Meeting #34 - 5 May 2022

[Emily Barabas]

Dear all,

Please find below the notes from today’s meeting on Thursday, 5 May 2022 at 13:30 UTC.

Kind regards,

Ariel, Steve, and Emily



Notes – IDNs EPDP Call – 5 May 2022

Welcome & Chair Updates

  *   SSAC has issued SAC 120. A copy was forwarded to the EPDP mailing list. The document reiterates points raised in the last meeting between SSAC members and EPDP. EPDP Team will consider whether another call should be scheduled with members of SSAC.
  *   Outreach letter to CJK GPs has gone out. Leadership team will provide updates once responses have been received.
  *   Draft text for A7 part 1, A9, and A10 will be circulated soon with two weeks for members to provide suggested amendments. If members submit substantive comments, these will be discussed on a future call.
  *   As a reminder, the leadership team is seeking volunteers for a small team to look at string similarity issues. Please respond by tomorrow if interested.

Continue discussion of charter question e5, including review of data collected by ICANN org

  *   Slide 4 – background on Charter E5 and context
  *   Slide 5 – recap: reserved names
  *   Analysis of reserved names and 11 test labels – the org team ran labels through the RZ-LGR to identify variant labels. The first tab provides a summary, Column C shows the total number of variants. D, E, and F provide breakdown of allocatable, blocked and variant labels. In the subsequent tabs you can see the list of variants for each.
  *   Comment: The mechanism generates a lot of potential strings that might not ultimately be useful for anyone or used. Suggestion to list strings that are disallowed by policy in a separate category in the spreadsheet (for example those that use a mix of different scripts).
  *   Comment: If we are thinking about variants to the reserved names list, the variants list should only include those that could actually be applied for. A string including a mix of scripts would not be included, for example. Maybe that list would be smaller. If there is going to be a visual similarity test anyway, the question is which strings do we really need to add, since it’s going to be handled in the string similarity review anyway?
  *   Staff comment: If variants of Reserved Strings are also considered as Reserved Strings, this would mean that they would be included in the string similarity review. The implication is that every applied-for string is compared against a much larger pool of reserved names.
  *   Comment: If there are variants of a reserved name that would not be captured in the string similarity review, those are the ones we should focus on and potentially add to the reserved names list.
  *   Comment: It is unclear where the problem is. If this is going to come up in the string similarity process, why do we have to worry about adding it to the reserved name list?
  *   Comment: If we simply say in the AGB that all reserved names and variants are reserved rather than listing each of the variants, we would end up in the same place. People can use the RZ-LGR to generate the variants check. Or we allow the string similarity review to take care of it. Either way we go about it, we end up with the same outcome.
  *   Comment: If the algorithm can be modified to focus only on variants that are composed of a single script, that would bring the number of variants in question down significantly.
  *   Question: Is it possible to identify an example of a string that is a variant that would not be considered visually similar? This could be used to look at a scenario where a one string looks like a variant of a reserved name.
  *   Example:  ssac vs. ßac are variants. If BAC and ßac are visually similar, should it be possible to apply for BAC? From one perspective, it should be possible.
  *   Comment: One issue is variants the other is string similarity. Both can occur for applied for strings as well as for reserved names and other strings that cannot be applied for. The Staff report suggested a coherent analysis looking at all the possible TLD strings across all categories rather than offering one approach for an applied for string and different rules for reserved names.
  *   Comment: We shouldn’t block BAC just because ßac is a variant of ssac. All blocked labels plus variants should be blocked but string similarity should analysis should only be done with those on the block list and not variants of those on the block list.
  *   Comment: This should apply not only to reserved names, but also to existing and applied for strings. In the next round, if someone applies for a string, the string similarity review should only be done on those strings that were delegated and not the variants were not delegated. The string similarity review that is done on reserved names is the same as on existing TLDs and other applications. The implications are different but the test is the same.
  *   Staff comment: For scripts like Arabic, that may have a different perspective as well.
  *   Staff note: Looking again at the charter question: Should the list of reserved names be updated to include variants of reserved names, so that those would also be taken into account in the string similarity review?
  *   Question: Is it correct that the group is converging on the idea that a variant label of a reserved name is a different category from a reserved name and that those variants do not need to be added to the list of reserved names, they just need to be blocked?
  *   Comment: They shouldn’t be added. The reserved strings are reserved for a purpose. If an application comes up that looks like the reserved name, this will be addressed in the string similarity review. If there is a variant that looks different from the reserved name, it should not be taken into account in the string similarity review. Adding to the reserved names list should not be taken lightly. A lot of thought went into making this list. The trend over time has been to limit the reserved names.
  *   Comment: In case there is any possibility of re-evaluation of the blocked string or variant it should be included. If there is no possibility of reversing the status of a blocked variant, it should not be included.
  *   Comment: We should leave the list as it is and state that all variants of those labels will be automatically blocked. ßac (variant of ssac) should be blocked even if it would not have been caught in the string similarity review because it is not visually similar. There may be old browsers that might format the string ßac into ssac which may cause a real problem.
  *   General support expressed for the idea that the reserved name list should not be updated. Variants of reserved names will be blocked but will not be taken into account in the string similarity review.
  *   Slide 6 & 7 – Strings ineligible for delegation
  *   Comment: Don’t extend the list via this group. The policy has a process to extend the list. To extent there is an interest from those groups to extend the list, they can follow the specified process.
  *   Comment: We are not extending the protection, we are upholding the variant process. We need to have a consistent way to apply variants across all strings so it’s clear for everyone. We should focus less on the numbers of protected strings and focus more on whether we are approaching this issue in a principled manner.
  *   Comment: One of the fundamental principles is that a label and its variants are allocated to the same entity. If this is not extended there is a possibility that a variant is allocated to an entity that is different from the IGO or INGO, which breaks that principle, which is a significant change.
  *   Comment: We are not adding to the list if we include variants. We are protecting labels already on the list. Variants are considered “the same.” Therefore, all variants of the labels on the list must be blocked too, otherwise a different party from the IGOs can register a variant and take the original label away from that organization.
  *   Comment: Names that are ineligible for delegation are not reserved for the organization. If ineligible for delegation, it’s ineligible for all. We should not modify work that took years to complete. Before we go any further on this topic, Council should weigh in on whether this is in scope for the EPDP.
  *   Comment: To avoid long lists, we should take as a principle that lists contain the “originals” and then link to a resource for calculating variants.


Begin review of charter questions e2 and e1, part 2

  *   Slide 9 – Charter questions E2 & E1 (part 2)
  *   Slide 10 – Objections – Applications Process Flow Chart
  *   Slide 11 – Objection process in the 2012 round
  *   Slide 12 – Discussion scope and questions, as well as staff paper context


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