[Gnso-epdp-idn-team] 回复: Your Input Requested: String Similarity Review Level & Rationale

[Zhang Zuan]

Hi all,

My personal rationale is as follows.
I apologize for responding so late, much approaching today’s call, leaving less time for folks to digest.

Why do you believe your preferred level of review is the most appropriate?

I would prefer a Level of 1.3 (a combination of Level 1 and Level 3):
Primary + only requested allocatable variants, Compared Against:
a.Reserved names
b.Existing TLDs + All variants (Allocatable & Blocked)
c.Strings requested as IDN ccTLDs + All variants (Allocatable & Blocked)
d.Other applied-for gTLDs + All variants (Allocatable & Blocked)

Let me explain why I have such a preference.

As is known to us, to conduct string similarity reviews, there are two sets we compare, let’s name them, Set A and Set B.

Set A is the strings we would like to compare.
Set B is the strings that are compared against.

In my preference,
Set A refers to : Primary + only requested allocatable variants
Set B refers to :
a.Reserved names
b.Existing TLDs + All variants (Allocatable & Blocked)
c.Strings requested as IDN ccTLDs + All variants (Allocatable & Blocked)
d.Other applied-for gTLDs + All variants (Allocatable & Blocked)

For Set A, compared to Set A of Level 1 and Level 2, Level 3 includes all blocked variants of the applied-for gTLDs. Since blocked variants of Set A are already blocked for whatever reasons, there is no necessity to compare the blocked variants of Set A. So Level 3 would not be considered.

Still for Set A, after we exclude blocked variants, when it comes to allocatable variants, please note that it may include requested allocatable variant(s) and non-requested allocatable variant(s). The difference is that it’s the applicant’s option to decide when to request activation of a variant. Those that are not requested activation are “non-requested allocatable variants”.

However, it is the “non-requested allocatable variants” that makes things complicated. Let’s see how.
 (Now only Level 1 and Level 2 are considered, Level 3 is not considered）

For Set A, in the case of Level 2, if all the allocatable variants have undergone string similarity reviews, no confusion are found out, however, Company A does not decide to request activation of their allocatable variants in gTLD appliction Round A.

In accordance with the principle of “first come first served”, Company B shall not be prohibited from applying for and requesting activation of their gTLD or its allocatable variants in Round A or later Rounds, which even though are later proved to be coincidentally confusingly similar with the allocatable variants that Company A may have had the chance to request activation but did not request activation. "First come first served" principle also applys to activation of variants. "Allocatable" does not equal to "activation".

So it is not necessary to compare all of the allocatable variants of Set A unless Company A requests activation of all of their allocatable variants of Set A, which then becomes the case of Level 1.

For Set A, in the case of Level 1, if it only includes the only requested allocatable variant, then if an applicant decides to activate any other non-requested allocatable variant, additional string similarity reviews shall be conducted against Set B.

Saying so, my preferred Set A, Primary + only requested allocatable variant, is the most appropriate. Set A should be as minimal as possible.

Let’s look into Set B.

For Set B, it may be agreed by all that it is a principle that to avoid any user confusion to the maximal extent, all variants of Set B should be compared against, as there is possibility that a requested allocatable variant of Set A is confusingly similar to a blocked variant of Set B. If a requested allocatable variant of Set A is confusingly similar to any variant of Set B, to prevent from user confusion, that allocatable variant of Set A should be blocked. Compared to the Set B of Level 1 and Level 2, Set B of Level 3 includes all blocked variants of existing TLDs, IDN ccTLDs, other applied-for gTLDs.

So, for Set B, it should be maximally conservative.

With the above rationale, I would prefer a Level named 1.3, a combination of Set A of Level 1 and Set B of Level 3.


Based on your preferred level of review, what would be the string similarity review’s impact on preventing user confusion and security/stability issues in the DNS? In other words, how effective would string similarity review be in preventing delegation of similar strings?

To conduct effective string similarity reviews, to avoid delegation of similar strings, recall that the principle is that the Set B shall be as maximal as possible. By doing so, it is highly impossible to delegate similar strings against Set B.

Have you considered the feasibility of implementing the string similarity review based on your preferred level? For example, the complexity and costs involved to conduct the resulting review.

For my preferred level, Primary+only requested allocatable variant (Set A), it is as minimal as possible, is easier to compare, and saves time and money.

With regards to Set B, using the RZ-LGR to calculate all of the variants of Set B, we keep the maximally conservative principle to compare against Set B. Time and money should be consumed as it should be.

Best Regards
Zuan Zhang
________________________________
发件人: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces at icann.org> 代表 Ariel Liang <ariel.liang at icann.org>
发送时间: 2022年4月21日 1:59
收件人: gnso-epdp-idn-team at icann.org <gnso-epdp-idn-team at icann.org>
主题: [Gnso-epdp-idn-team] Your Input Requested: String Similarity Review Level & Rationale


Dear EPDP Team,



Thank you for the discussions to date on the string similarity review topic (charter questions E3, E1 (part1) and E3a). The leadership team appreciates that this is a difficult topic and that a range of views are evident across the Team, particularly on the three levels of string similarity review<https://community.icann.org/download/attachments/192217195/EPDP%20Team%20Meeting%20%2330%20Slides%20-%20E3%2C%20E1%2C%20E3a.pdf?version=1&modificationDate=1649976844000&api=v2>.



In order to facilitate the continued deliberation of this topic, the Leadership Team requests members to consider the three levels of string similarity review and indicate your preferred level of review, along with the reasons why this is your preferred level, on the list by Wednesday, 27 April 2022.



When sharing your preference, please include responses to the following questions:



  1.  Why do you believe your preferred level of review is the most appropriate?
  2.  Based on your preferred level of review, what would be the string similarity review’s impact on preventing user confusion and security/stability issues in the DNS? In other words, how effective would string similarity review be in preventing delegation of similar strings?
  3.  Have you considered the feasibility of implementing the string similarity review based on your preferred level? For example, the complexity and costs involved to conduct the resulting review.



The string similarity review topic is expected to be discussed again during the EPDP Team meeting next week (28 April 2022) and members and participants will be invited to speak to their respective preferences and rationales. As a reminder, the three levels are as follows (please see details in the slide deck<https://community.icann.org/download/attachments/192217195/EPDP%20Team%20Meeting%20%2330%20Slides%20-%20E3%2C%20E1%2C%20E3a.pdf?version=1&modificationDate=1649976844000&api=v2>):

  *   Level 1: Primary + ONLY Requested Allocatable Variants
  *   Level 2: Primary + ALL Allocatable Variants
  *   Level 3: Primary + ALL Allocatable and Blocked Variants

Thank you for your contribution!



Best Regards,

Steve, Emily, Ariel




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