[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #33 - 28 April 2022

Thu Apr 28 19:26:42 UTC 2022

Emily

Good evening and thanks for this.

Apologies for missing meeting today. Crisis in the office, so to speak

Best

Nigel

On Thu, 28 Apr 2022, 18:31 Emily Barabas, <emily.barabas at icann.org> wrote:

> Dear all,
>
>
>
> Please find below the notes and action items from today’s meeting on
> Thursday, 28 April 2022 at 13:30 UTC.
>
>
>
> Kind regards,
>
>
>
> Ariel, Steve, and Emily
>
>
>
>
>
>
>
> *Action Items:*
>
>
>
> *Action Item 1*: Staff to request volunteers to join a small group tasked
> with developing examples related to Levels 1, 2, and 3. Staff to circulate
> a doodle to find a time for the small group to meet.
>
>
>
> *Notes – IDNs EPDP Call – 28 April 2022*
>
>
>
> Welcome & Chair Updates (5 minutes)
>
>    - On today’s call EPDP Team members will be able to explain their
>    responses on the mailing list regarding the three “levels” so that the
>    group can try to converge on an approach to Charter Questions E3, E1 (Part
>    1), and E3a.
>
>
>
> Charter Questions E3, E1 (part 1), E3a – Continued Discussion of the Three
> Levels (50 min)
>
>    - Slide 4 – overview of Charter Questions E3, E1 (part 1), E3a
>    - Slide 5 – Comparison matrix – explanatory notes
>    - Slide 6 – Comparison matrix – consolidated view
>    - Slide 7 – Comparison matrix – factors for consideration
>       - Comment: In Level 1, all entities will know that they can get the
>       strings they apply for and if they apply in the future, they may not be
>       able to get them based on the review for confusing similarity. The EPDP
>       Team member disagrees with the consequences listed on the slide. Level 1,
>       2, and 3 all guarantee that there will be no confusability. None provides
>       better protection than another in this regard.
>    - Slide 8 – Level 1: Primary + ONLY requested allocatable variants
>       - Comment: Support this option if variants can only be requested
>       inside application rounds. This is not a contribution on behalf of RySG.
>       RySG does not have a position on this topic. This level is sufficient
>       because it is a safeguard against allocating variants that would be
>       confusable to other strings that are allocated. There is no need to check
>       any future potential confusability of labels that may never be applied for
>       or allocated. That would only restrict the space without any really
>       necessity.
>       - Comment: Support for the above comment. No need to restrict the
>       space without reason. Level 1 does not restrict the space without reason,
>       entails the least similarity work, and involves the lowest cost. The only
>       drawback is that if an entity does not apply for an allocatable variant
>       initially it might not be able to get it later. But if the applicant knows
>       this from the beginning, it can apply for the variants it wants at the
>       outset. All three levels are the same in terms on avoiding confusability.
>       Whether level 1 or 2 is better depends on costs associated and whether
>       applicants can activate strings only within rounds or at any time.
>    - Slide 9 – Primary + ALL Allocatable Variants
>       - Comment: Support this option if variants can be requested outside
>       of application rounds. If a registry can request any allocatable variant at
>       any time, level 1 is not enough. In this case, at the application round of
>       the originally applied for TLD we need to check all of the allocatable
>       variants. We need to ensure from the start that these allocations will be
>       possible.
>       - Comment: Support for level 2 because it narrows the chances of
>       confusability in the same round which improves predictability. It presents
>       a good balance from a cost perspective.
>       - Comment: Support because it provides flexibility and opportunity
>       while ensuring a degree of protection of confusability.
>       - Comment: Some support depending on other elements such as costs
>       associated with each string applied for and when a string could be applied
>       for. Allows entity to ensure that all of their allocatable strings and all
>       other possible future similar strings would be blocked. This creates
>       predictability because all entities have their original string and
>       allocatable variants. No other TLD in the future could apply for those
>       allocatable variants. This is a good middle ground.
>       - Comment: ALAC supports Level 1 if costs associated with the
>       applied for string is high. In such a case Level 2 doesn’t make sense. If
>       the cost is relatively low, Level 2 is more appropriate. From the
>       perspective of confusability, they all provide the same level of
>       protection.
>    - Slide 10 – Level 3: Primary + ALL Variants
>       - Comment: Support for level 3, with continuous technological
>       improvements in improvements in reducing Risk Evaluation time of
>       assessment. Suggestion to use AI to support the evaluation. The EPDP Team
>       previously discussed that AI may not be able to be leveraged for this
>       purpose.
>       - Comment: There are many complaints about misuse of domain (mainly
>       .brands). String similarity can cause more issues.
>       - Comment: We might also need to think about if we go with Level 1
>       or 2, what does first come first serve mean when prior round applicants
>       activate variants. In the case of Level 3, that would not be an issue. In
>       the case of 1 and 2 that would be an extra point of consideration.
>       - Comment: In Level 2 all would have been taken care of as well.
>       - Comment: We have been looking at this from the perspective of
>       applicants, but we also want to make the space less confusing from an end
>       user perspective. This is the underlying motivation of string similarity
>       review. Examples: At the second level, if we have myname.com vs.
>       myname.org there is no confusability. If we replace .com and .org
>       with strings that are similar – myname.tld vs. myname.tld’ where tld’ is
>       very similar to .tld, this might be confusing for the end user. If
>       myname.tld is similar to a variant of another TLD that is delegated there
>       could still be confusability from an end user perspective through a
>       transitive relationship. Irrespective to whether the variant is
>       allocatable, blocked, etc, there can still be confusability when there are
>       two similar strings in the DNS space.
>       - Example: Simplified and traditional Chinese – in most cases the
>       two are visually distinct. If applicant A applies for a simplified Chinese
>       version, which has a traditional version that looks different but is
>       considered to be the same in meaning and has not been applied for. If
>       applicant B applies for a traditional Chinese character that is visually
>       very similar to traditional variants of the simplified character applied
>       for by applicant A. If the comparison is done only for applied-for strings,
>       the applied-for strings for applicant A and b will both be delegated, the
>       end users can get confused by seeing the traditional version is the same as
>       the simplified version. This will create confusion for all registrations
>       under those TLDs. Level 1 will not prevent this scenario.
>       - Comment: Preference for a combination of level 1 and level 3. For
>       string similarity review there are two things to compare, Set A and Set B.
>       If it includes variants there is Set A and Set B. Set A is the strings we
>       would like to compare. Set B is the strings we compare against. Set A
>       includes primary + only requested allocatable variants. Set B it includes
>       reserved names, existing TLDs + All variants (allocatable and blocked
>       variants), strings requested as IDN ccTLDs and all variants allocatable and
>       blocked, other applied for gTLDs and all variants allocatable and blocked.
>       The core of the problem is whether we allow applicants to request variants
>       outside of a round. We should focus on Set B, which can decide what is
>       similar or not. To meet the conservativism principle, Level 3 is best.
>       Therefore, Set 1 is Level 1 and Set B is Level 3.
>    - Discussion
>       - Comment: Confusing similarity has always been only about visual
>       similarity. Applying that principle, the maximum conservative approach is
>       not consistent with the way we have always approached these things. How
>       would this look in the case of variants that are not visually similar? How
>       would this be any different from a case of two strings that have the same
>       meaning but look different? It’s hard to compare these levels without
>       examples. Why would we give additional protections here?
>       - Response: The difference is 1. color vs. colour and 2. color vs
>       COLOR. The example above is talking about case 1, IDN Variants is
>       closer to case 2, whereas in English alphanumeric is how we deal with it
>       today it is 'the same' but with IDN, we have a situation of 2. that is
>       technically not the same but linquistically the same.
>       - Comment: We have already acknowledged that the treatment of IDNs
>       and variants is different from other strings.
>       - Comment: That is the case within a variant set, but it is another
>       level when we are talking about similarity across variant sets.
>       - Comment: The primary position from ALAC is Level 2, but this
>       position is conditional and some additional discussion might be needed.
>       Examples would be helpful to support additional deliberations on this
>       topic.
>       - Question: If we reached an agreement on whether when you apply
>       for the IDN and apply for the variants you want, it is done in a round,
>       does this overcome any of the differences in this discussion?
>       - Response: No, this would not necessarily settle the issue.
>       - Comment: Agree that this would not resolve the issue. But if you
>       go with Level 2 it should be possible to activate variants between rounds.
>       - Comment: We should think about activation of variants like
>       updating nameserver or updating the backend. It should involve technical
>       checks but should be possible at any time. Allocating in rounds is not a
>       good starting point. We should look at actual examples that address these
>       issues visually. Maybe a small group should put some examples together.
>       - Comment: Agree that this should be the case if you are activating
>       a variant you already expressed interest for in an application. Disagree if
>       the registry has not previously expressed interest in through an
>       application. This is consistent with the SSAC advice, because applicants
>       will have to explain how they can handle the variants and these statements
>       need to evaluated.
>
>
>
> *Action Item 1:* Staff to request volunteers to join a small group tasked
> with developing examples related to Levels 1, 2, and 3. Staff to circulate
> a doodle to find a time for the small group to meet.
>
>
>
> AOB
>
>    - Reminder to provide feedback on the outreach letter to GPs by
>    Friday. It has been shared on the mailing list.
>
>
> _______________________________________________
> Gnso-epdp-idn-team mailing list
> Gnso-epdp-idn-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220428/7bed9c11/attachment-0001.html>