<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<span style="font-size: 14pt;">Hi all,</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<div><br>
</div>
<div><span style="font-size: 14pt;">My personal rationale is as follows.</span></div>
<div><span style="font-size: 14pt;">I apologize for responding so late, much approaching today’s call, leaving less time for folks to digest.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;"><b>Why do you believe your preferred level of review is the most appropriate?
</b></span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">I would prefer a Level of 1.3 (a combination of Level 1 and Level 3):</span></div>
<div><span style="font-size: 14pt;">Primary + only requested allocatable variants, Compared Against:</span></div>
<div><span style="font-size: 14pt;">a.Reserved names</span></div>
<div><span style="font-size: 14pt;">b.Existing TLDs + All variants (Allocatable & Blocked)</span></div>
<div><span style="font-size: 14pt;">c.Strings requested as IDN ccTLDs + All variants (Allocatable & Blocked)</span></div>
<div><span style="font-size: 14pt;">d.Other applied-for gTLDs + All variants (Allocatable & Blocked)</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">Let me explain why I have such a preference.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">Set A is the strings we would like to compare.</span></div>
<div><span style="font-size: 14pt;">Set B is the strings that are compared against.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">In my preference, </span></div>
<div><span style="font-size: 14pt;">Set A refers to : Primary + only requested allocatable variants</span></div>
<div><span style="font-size: 14pt;">Set B refers to : </span></div>
<div><span style="font-size: 14pt;">a.Reserved names</span></div>
<div><span style="font-size: 14pt;">b.Existing TLDs + All variants (Allocatable & Blocked)</span></div>
<div><span style="font-size: 14pt;">c.Strings requested as IDN ccTLDs + All variants (Allocatable & Blocked)</span></div>
<div><span style="font-size: 14pt;">d.Other applied-for gTLDs + All variants (Allocatable & Blocked)</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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”.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt; color: rgb(222, 106, 25);">However, it is the “non-requested allocatable variants” that makes things complicated. Let’s see how.</span></div>
<div><span style="font-size: 14pt;"> (Now only Level 1 and Level 2 are considered, Level 3 is not considered）</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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. </span></div>
<div><span style="font-size: 14pt;"><br>
</span></div>
<div><span style="font-size: 14pt;">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 <span style="background-color:rgb(255, 255, 255);display:inline !important">
later<span> </span></span>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".</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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. </span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">Saying so, my preferred Set A, Primary + only requested allocatable variant, is the most appropriate. Set A should be as minimal as possible.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">Let’s look into Set B.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">So, for Set B, it should be maximally conservative.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;"><b><br>
</b></span></div>
<div><span style="font-size: 14pt;"><b>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? </b></span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;"><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.
</b></span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">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.</span></div>
<div><span style="font-size: 14pt;"><br>
</span></div>
<div><span style="font-size: 14pt;">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.</span></div>
<div><br>
</div>
<div><span style="font-size: 14pt;">Best Regards</span></div>
<div><span style="font-size: 14pt;">Zuan Zhang</span></div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>发件人:</b> Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> 代表 Ariel Liang <ariel.liang@icann.org><br>
<b>发送时间:</b> 2022年4月21日 1:59<br>
<b>收件人:</b> gnso-epdp-idn-team@icann.org <gnso-epdp-idn-team@icann.org><br>
<b>主题:</b> [Gnso-epdp-idn-team] Your Input Requested: String Similarity Review Level & Rationale</font>
<div> </div>
</div>
<style>
<!--
@font-face
{font-family:Wingdings}
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:DengXian}
@font-face
{font-family:Calibri}
@font-face
{}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
a:link, span.x_MsoHyperlink
{color:#0563C1;
text-decoration:underline}
span.x_EmailStyle17
{font-family:"Calibri",sans-serif;
color:windowtext}
.x_MsoChpDefault
{font-family:"Calibri",sans-serif}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
div.x_WordSection1
{}
ol
{margin-bottom:0in}
ul
{margin-bottom:0in}
-->
</style>
<div lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="x_WordSection1">
<p style="margin:0in"><span style="color:black">Dear EPDP Team, </span></p>
<p class="x_MsoNormal"> </p>
<p style="margin:0in"><span style="color:black">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 </span><a href="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"><span style="color:#1155CC">three
levels of string similarity review</span></a><span style="color:black">.</span></p>
<p class="x_MsoNormal"> </p>
<p style="margin:0in"><span style="color:black">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
<b><u>indicate your preferred level of review, along with the reasons why this is your preferred level, on the list by Wednesday, 27 April 2022. </u></b></span></p>
<p class="x_MsoNormal"> </p>
<p style="margin:0in"><span style="color:black">When sharing your preference, please include responses to the following questions: </span></p>
<p style="margin:0in"> </p>
<ol start="1" type="1" style="margin-top:0in">
<li style="color:black; margin-top:0in; margin-bottom:10.0pt; vertical-align:baseline">
Why do you believe your preferred level of review is the most appropriate? </li><li style="color:black; margin-top:0in; margin-bottom:10.0pt; vertical-align:baseline">
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? </li><li style="color:black; margin-top:0in; margin-bottom:10.0pt; vertical-align:baseline">
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. </li></ol>
<p style="margin-right:0in; margin-bottom:10.0pt; margin-left:0in"><span style="color:black"> </span></p>
<p style="margin-right:0in; margin-bottom:10.0pt; margin-left:0in"><span style="color:black">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
</span><a href="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"><span style="color:#1155CC">slide deck</span></a><span style="color:black">): </span></p>
<ul type="disc" style="margin-top:0in">
<li style="color:black; margin-top:0in; margin-bottom:0in; vertical-align:baseline">
<b>Level 1</b>: Primary + ONLY Requested Allocatable Variants </li><li style="color:black; margin-top:0in; margin-bottom:0in; vertical-align:baseline">
<b>Level 2</b>: Primary + ALL Allocatable Variants </li><li style="color:black; margin-top:0in; margin-bottom:10.0pt; vertical-align:baseline">
<b>Level 3</b>: Primary + ALL Allocatable and Blocked Variants </li></ul>
<p style="margin-right:0in; margin-bottom:10.0pt; margin-left:0in"><span style="color:black">Thank you for your contribution!</span></p>
<p class="x_MsoNormal"> </p>
<p style="margin-right:0in; margin-bottom:10.0pt; margin-left:0in"><span style="color:black">Best Regards,</span></p>
<p style="margin-right:0in; margin-bottom:10.0pt; margin-left:0in"><span style="color:black">Steve, Emily, Ariel </span></p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal"> </p>
</div>
</div>
</body>
</html>