[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #48 - 18 August 2022

[Emily Barabas]

Dear all,

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

Kind regards,

Ariel, Steve, and Emily



Notes and Action Items - IDNs EPDP Call – 18 August 2022

Welcome & Chair Updates

  *   Reminder: Ariel has put new text on the mailing list to review with a deadline of August 31.
  *   Today’s focus will the small group recommendations on objections processes, which will hopefully help the conversation on String Similarity Evaluation. The leadership team will be seeking input on both pieces of the small group’s work in the coming weeks.
  *   Next week’s call will be moved 24 hours later than usual (Friday, 26 August at 13:30 UTC) to avoid conflict with the GNSO Council call.
  *   Leadership team is thinking about the organization of sessions in KL. This will be brought back to the EPDP Team soon.

Presentation of small group outputs on objection processes

  *   The small group has completed its work, which is divided into two parts. The first part was presented last week and the second part will be presented today.
  *   Slide 19 – Task 3 overview
  *   Slide 20 – Discussion – For each type of objection process, which types of strings/labels must be taken into account?
  *   Slide 21 – General Assumptions for Objection Process Discussion
  *   Slide 22 – String Confusion Objection: Background
  *   Slide 23 – String Confusion Objection: Questions for Consideration
  *   Slide 24 – String Confusion Objection: Recommendation
     *   Note: Recommended approach is consistent with the “hybrid” model proposed by the small group for the String Similarity Review.
     *   Question: Anyone can file an objection. Is this about prevailing? A string objection can always be filed. The question is whether they can prevail if they are successful.
     *   Response: What this means is that the objection process is available to an existing TLD operator or applicant if they can make the case of whether it is confusingly similar for these specific types of strings. It is up to the panel to decide if they prevail.
     *   Follow up: Is it correct that for point 5 on slide 24, if an existing TLD operator can show that an applied for string’s allocatable variant is confusingly similar to its own allocatable variant, it will prevail?
     *   Response: We are not saying what is going to prevail and what is not going to prevail. We are talking about the basis on which objections can happen. For example, you can’t file on the basis of confusingly similarity between two blocked variants. The small team does not believe that all kinds of objections would be accommodated. The small group is not saying what will and will not succeed.
     *   Follow up: The small group is saying that with the exception of blocked against blocked, an objection can be made on the grounds of confusing similarity between the other pairs.  This implies that they can win a challenge based on any of those cases where they can file.
     *   Response: Confirmed.
     *   Question: If an objector has certain variants that are blocked, why would an objector be able to prevail if they show that the blocked variants are confusingly similar to an applied-for string?
     *   Response: String confusion objection is not just about visual similarity but also other forms of similarity. The whole variant set is intended to mean the same thing. So this case can result in misconnection. The small group thinks it’s important for the blocked variants to be included in the analysis.
     *   Comment: Looking at slide 23, if B3-B12 are confusingly similar to A1, why can’t B1 go forward?
     *   Response: The Internet end-user doesn’t know or care about blocked variants. Even though that the label is blocked and won’t be in the root, the labels in the set are regarded as the same. Even if blocked, the variant could still be mistaken for something else, and therefore the blocked variants should be taken into account in objections.
     *   Comment: Synonyms are alike, and there may be confusion between them, that is not enough to prevail in an objection.
     *   Comment: The example of synonyms is not the same as variants. Variants are not just about the same meaning, it’s a different way of writing the same word.
     *   Comment: Regarding examples, in last week’s meeting, we used the Arabic script example on slide 15 – A1 and B3 look almost exactly the same. If A1 and B1 are both delegated, someone might mistake B3 for A1.
     *   Comment: Even if blocked variants can’t exist in the root zone, they may exist in a language, so there is a risk of misconnection. The user may encounter that variant in another context.
     *   Comment: From one perspective, A1 and B1 are similar, so the objection would likely be based on similarity between those two strings. The slide 15 example is not helpful for this discussion.
     *   Question: On slide 23 – how can we deny a mark the use of their name because the string is confusingly similar to the blocked variant of an artist’s name?
     *   Response: We are compromising on what we think is appropriate.
     *   Response: We are talking about top-level domains. In all real life examples, there will always be another label before. If there is a domain X.A1, you you might think you are seeing a label X.B6, because it seems to be the same. If you type X.B6 it won’t work. But if you think that X.B1 and X.B6 are the same, and you type X.B1 and you don’t get where you expect. This is a problem.
     *   Comment: It is possible to provide any example with a trademark – anyone who types my trademark might end up at a website not controlled by the entity they expect. We have to let legitimate uses to coexist.
     *   Comment: Another observation on blocked variants – many labels are not well-formed. For instance, the label mixes more than one script, which is prohibited e.g., a label mixing Latin, Cyrillic and Greek. There is no value in having these mix-script labels incorporated in String Similarity Review.
  *   Slide 25 – Limited Public Interest Objection
  *   Slide 26 – Limited Public Interest Objection: Questions for Consideration
  *   Slide 27 – Limited Public Interest: Recommendation
     *   Question: Is it possible to give an example of how this would work in practice? Can you have a definitive rule? Is it possible that sometimes variants can be addressed by the same concern and at other times not?
     *   Response: It depends on whether the applicant has requested variants along with the primary string. If the applicant only applies for the primary string, the objection can be against the primary string. If the applicant applies for a primary string and allocatable variants, the objector could, for example, object against the whole set and then if the objector prevails, the whole set will not proceed.
  *   Slide 28 -- Legal Rights Objection: Background
  *   Slide 29 – Legal Rights Objection: Questions for Consideration
  *   Slide 30 – Legal Rights Objection: Recommendation (Option 1)
  *   Slide 31 – Legal Rights Objection: Recommendation (Option 2)
     *   Clarification: The higher bar in doesn’t mean that a new standard for objections is being considered. It is intended to mean that proving harm from a non-requested allocatable variant or a blocked variant will naturally be more difficult.
  *   Slide 32 – Legal Rights Objection: Recommendation (Option 2) – Additional Rationale
     *   Comment: Premise for all objections should not be preventing failure mode. We should go with option 1 and extend to string similarity. Existing registries shouldn’t have more rights than rights holders.
     *   Comment: Many of the blocked variants are a mix of related scripts. There is a general prohibition on mixed script strings. They are not meant to be delegated. Do not agree including blocked variants in these processes, but if you do include them, you would need to create an extra step to factor in whether blocked variants are mixed script.
     *   Comment: Additional support for the idea that if ill-formed labels automatically become blocked as per the RZ-LGR, they should not be used for review.
     *   Response: Agree that there may be several blocked variants that would never exist (neither as domain or in real life), but we can ignore this special case of blocked variants. If someone wants to make a case with blocked variants, let them do it. The panel will certainly reject it then. It makes it more complex to also start distinguishing between "sensible" labels and "non-sensible" labels.
     *   Response: The issue is if there is a script that is commonly used for multiple languages it could be a cause for confusion.
  *   Slide 33 – Community Objection: Background
  *   Slide 34 – Community Objection: Questions for Discussion
  *   Slide 35 – Community Objection: Recommendation (Option 1)
  *   Slide 36 – Community Objection: Recommendation (Option 2)
  *   Slide 37 – Community Objection: Recommendation (Option 2) – Additional Rationale
  *   Summary comments: The small group looked at narrowly scoped questions, but did not look at implementation, so the EPDP Team needs to continue the discussion to consider the potential implications of recommendations and whether they can be implemented.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220818/f42408c5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Package_ Report String Similarity Small Group Outcome (1).pdf
Type: application/pdf
Size: 2169699 bytes
Desc: Package_ Report String Similarity Small Group Outcome (1).pdf
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220818/f42408c5/Package_ReportStringSimilaritySmallGroupOutcome1-0001.pdf>