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
Dear Ariel, Emily, Steve, dear team colleagues, my preference is either Level 1 or Level 2, depending on whether new variants can be "added/applied for" outside of "application rounds". Let me explain my decision for each level. Level 3 ======= I don't think Level 3 is required. It's a lot of additional effort, but it is not really giving important input. See the following abstract and very reduced example. Applied for TLD labels: * A (with blocked variant A1) * B (with no variants) Assumption: String similarity says B and A1 are confusingly similar. However, and that's important, A and B are *not* confusingly similar (if they were this example would be irrelevant for this question). Rationale: If we go for Level 3, then only either A or B (or none) can be delegated, but not both. I see no benefit in this restriction: Obviously (by assumption) A and B won't be confused. Also A won't be able to activate the TLD label A1. Thus, in my view, it's causing unnecessary work for the string similarity review and it's keeping one applicant form getting their TLD. Level 2 ======= If we allow adding of variants outside of application rounds, we need this level, simply because we don't want the string similarity review process to be started every time a TLD operator wants to add another variant. The late addition of variants must be as smooth and simple as possible. Any checks/validations that can be executed beforehand should be. Level 1 ======= If we allow adding of variants only in the initial application process and possibly during another application round (but not any arbitrary time in between), this is my preference. It reduces the effort to a minimum. There's no need to compare any allocatable variant that has not been requested so far. Possibility is high that it never will be requested. If such a variant does get requested in a later round, well, that's like a new application, it has to compete with all existing ones on a first come first serve basis (i.e., the existing ones take precedence). I think this already answers most items, but I'll nevertheless revisit the three explicit questions.
1. Why do you believe your preferred level of review is the most appropriate?
That's explained above.
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?
It would prevent user confusing, because any delegated string would undergo the string similarity review process. Similar to my argument under "Level 3", there's no benefit in comparing strings that will never be delegated (i.e., visible in the DNS). Just because a non-delegated variant of an existing TLD is confusingly similar to another TLD shouldn't cause those TLDs themselves to be blocking each other. They are *not* confusingly similar to each other.
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.
Yes, I have. :-) I suggest to only compare the labels that factually could be delegated (i.e., become visible in the DNS) until the next round of TLD application starts. This is the minimum requirement and I don't think we need more (actually more would even be harmful, see my arguments above). Please let me know, if anything in my arguments are difficult to understand, I'm happy to explain in more details. Best regards, Michael PS This is my personal view. The RrSG has not expressed any view itself. -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp
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@icann.org> 代表 Ariel Liang <ariel.liang@icann.org> 发送时间: 2022年4月21日 1:59 收件人: gnso-epdp-idn-team@icann.org <gnso-epdp-idn-team@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
participants (3)
-
Ariel Liang -
Michael Bauland -
Zhang Zuan