<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:CenturyGothic;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:12.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        font-size:12.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:19940409;
        mso-list-template-ids:160834260;}
@list l0:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1
        {mso-list-id:973486266;
        mso-list-type:hybrid;
        mso-list-template-ids:-866885578 -349252040 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:.75in;
        text-indent:-.25in;}
@list l1:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:1.25in;
        text-indent:-.25in;}
@list l1:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        margin-left:1.75in;
        text-indent:-9.0pt;}
@list l1:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:2.25in;
        text-indent:-.25in;}
@list l1:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:2.75in;
        text-indent:-.25in;}
@list l1:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        margin-left:3.25in;
        text-indent:-9.0pt;}
@list l1:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:3.75in;
        text-indent:-.25in;}
@list l1:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:4.25in;
        text-indent:-.25in;}
@list l1:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        margin-left:4.75in;
        text-indent:-9.0pt;}
@list l2
        {mso-list-id:1993483259;
        mso-list-template-ids:641789290;}
@list l2:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks for this explanation Dennis.  I still believe that there should be a challenge process for applicants even if the end result for an applicant is to just send it through the Label Generation Rules procedure. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">At the end of the day, at the time the LGR rules came out (or will come out in the future), many of the would-be applicants in future rounds may not be paying attention to ICANN, the LGR Rules, or the official
 challenge process.  It may not be until the applicant fails the DNS Stability evaluation that it realizes there was an official process to challenge the LGR for that script.  That could be years after the LGR was approved. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">All of this means that we cannot expect that applicants would have been aware of the LGR official challenge process, but applicants should be able to seek redress if it believes that the results were wrong
 (for whatever reason).  Therefore, I believe we should still have the challenge process for the corner case where this becomes an issue. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">To that end, I believe it is only the applicant that can challenge the result of the evaluation if it fails the String Similarity evaluation. It should not be challengeable by another 3<sup>rd</sup> party
 if the applicant passes the evaluation and the 3<sup>rd</sup> party believes that it should not have.  And I believe that the “arbiter” of the challenge should be a person from the Panel that performs the technical DNS Stability review (preferably one that
 did not evaluate the original application).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The arbiter looks at whether the LGR rules were applied appropriately and that the results were in fact justified under the current LGR rules. [I know the process is “automated”, but mistakes can always be
 made].   If the rules were applied appropriately and the results were correct, then the challenge should be denied and the Applicant encouraged to utilize the formal LGR procedure which would have effect in a subsequent round.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The applicant can on its own seek to modify the LGR rules through the official process, and if successful could resubmit its application in a
<b>subsequent round</b>, but in my opinion, it should not be allowed back in to that current round.  If the string would have been in a contention set in the current round, then the applicant may not be able to apply for the string it wanted in the next round
 (due to it being confusingly similar to at that point a granted string), but that is the risk the applicant takes.  I believe it would be such a corner case for an applicant to have its string fail a DNS Stability review in Round 2, succeed in modifying the
 LGR tables for round 3, but be prohibited from applying for it again because another string in Round 2 went through that is confusingly similar.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I hope all of that makes sense and I hope this proposal allows this issue to be resolved more quickly.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<table class="MsoTableGrid" border="1" cellspacing="0" cellpadding="0" style="border-collapse:collapse;border:none">
<tbody>
<tr>
<td width="192" valign="bottom" style="width:144.3pt;border:none;border-top:solid #06175F 3.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="text-align:justify"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black;border:none windowtext 1.0pt;padding:0in"><img width="178" height="81" style="width:1.8489in;height:.8437in" id="Picture_x0020_1" src="cid:image001.png@01D7B3D5.DFE03DE0"></span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</td>
<td width="173" valign="bottom" style="width:129.95pt;border:none;border-top:solid #06175F 3.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="text-align:justify"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:#06175F">Jeffrey J. Neuman</span><span style="font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Founder & CEO</span><span style="font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:#06175F">JJN Solutions, LLC</span><span style="font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">p: +1.202.549.5079</span><span style="font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">E:
</span><span style="font-family:"Times New Roman",serif"><a href="mailto:jeff@jjnsolutions.com"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:#1155CC">jeff@jjnsolutions.com</span></a><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">http://jjnsolutions.com</span><span style="font-family:"Times New Roman",serif"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt">From:</span></b><span style="font-size:11.0pt"> Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org>
<b>On Behalf Of </b>Tan Tanaka, Dennis via Gnso-epdp-idn-team<br>
<b>Sent:</b> Thursday, September 23, 2021 3:09 PM<br>
<b>To:</b> gnso-epdp-idn-team@icann.org<br>
<b>Subject:</b> [Gnso-epdp-idn-team] RZ-LGR and DNS stability review<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Hello —during today’s meeting some of you referred to the DNS stability review process as the function to determine whether an applied-for string if deemed fit for the root zone. I also observed that we might
 want to focus on the very limited function of the RZ-LGR, and to deal with contention sets and other evaluation procedures later on.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">To that end, I looked at the old applicant guide book and searched for the DNS stability: string requirements (2.2.1.3.2). Basically, string requirements is broken down into three parts: Part I (technical
 requirements for all labels, Part II (requirements for IDNs), and Part III (policy requirements for gTLDs).
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The RZ-LGR, I believe, is meant to “replace” or “automate” Parts I and II of the string requirements review process (a copy of the text is down below for your reference). In addition to those functions, also
 helps with the calculation of variant labels, so that the applicants don’t have to come up with IDN variant rules of their own.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The difference between the prior AGB and the RZ-LGR (if adopted), are
</span><o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:.25in;mso-list:l1 level1 lfo1"><span style="font-size:11.0pt">that the latter starts with a smaller universe of “valid” letters. Before RZ-LGR, virtually all protocol valid code points were available to be used
 in a TLD string (with exception of course of hyphen and digits). The RZ-LGR starts with a smaller repertoire than IDNA2008 (i.e. Maximal Starting Repertoire) which is further limited by each script generation panel. The result of each generation panel’s work
 is merged into the RZ-LGR. So, one applicant might challenge the RZ-LGR’s results because it did not accept one letter, or a combination or some script rule. This should be okay to challenge, but the process by which the applicant finds resolution would be
 through the established LGR procedure (i.e. make the case for inclusion of a new letter or rule) to maintain the stability of the RZ-LGR.</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:.25in;mso-list:l1 level1 lfo1"><span style="font-size:11.0pt">the RZ-LGR is designed to calculate the variant labels. The prior DNS stability review process did not do that; applicants were asked to provide these
 self-identified variant labels.</span><o:p></o:p></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I hope this helps the discussion.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Best,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Dennis</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p><b><i><span style="font-size:10.0pt;font-family:CenturyGothic">Part I -- Technical Requirements for all Labels (Strings)
</span></i></b><span style="font-size:10.0pt;font-family:CenturyGothic">– The technical requirements for top-level domain labels follow.
</span><o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo2">
<span style="font-size:10.0pt;font-family:CenturyGothic">1.1  The ASCII label (i.e., the label as transmitted on the wire) must be valid as specified in technical standards
<i>Domain Names: Implementation and Specification </i>(RFC 1035), and <i>Clarifications to the DNS Specification
</i>(RFC 2181) and any updates thereto. This includes the following: </span><span style="font-size:11.0pt"><o:p></o:p></span></li></ol>
<p style="margin-left:.75in"><span style="font-size:10.0pt;font-family:CenturyGothic">1.1.1  The label must have no more than 63 characters.
</span><o:p></o:p></p>
<p style="margin-left:.75in"><span style="font-size:10.0pt;font-family:CenturyGothic">1.1.2  Upper and lower case characters are treated as identical.
</span><o:p></o:p></p>
<ol start="2" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo2">
<span style="font-size:10.0pt;font-family:CenturyGothic">1.2  The ASCII label must be a valid host name, as specified in the technical standards
<i>DOD Internet Host Table Specification </i>(RFC 952), <i>Requirements for Internet Hosts — Application and Support
</i>(RFC 1123), and <i>Application Techniques for Checking and Transformation of Names (RFC 3696), Internationalized Domain Names in Applications (IDNA)(RFCs 5890-5894), and any updates thereto.
</i>This includes the following: </span><span style="font-size:11.0pt"><o:p></o:p></span></li></ol>
<p style="margin-left:.25in;text-indent:.5in"><span style="font-size:10.0pt;font-family:CenturyGothic">1.2.1 The ASCII label must consist entirely of letters (alphabetic characters a-z), or
</span><o:p></o:p></p>
<p style="margin-left:.25in;text-indent:.5in"><span style="font-size:10.0pt;font-family:CenturyGothic">1.2.2 The label must be a valid IDNA A-label (further restricted as described in Part II below).
</span><o:p></o:p></p>
<p><b><i><span style="font-size:10.0pt;font-family:CenturyGothic">Part II -- Requirements for Internationalized Domain Names
</span></i></b><o:p></o:p></p>
<p><i><span style="font-size:10.0pt;font-family:CenturyGothic">– </span></i><span style="font-size:10.0pt;font-family:CenturyGothic">These requirements apply only to prospective top-level domains that contain non-ASCII characters. Applicants for these internationalized
 top-level domain labels are expected to be familiar with the Internet Engineering Task Force (IETF) IDNA standards, Unicode standards, and the terminology associated with Internationalized Domain Names.
</span><o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3">
<span style="font-size:10.0pt;font-family:CenturyGothic">2.1  The label must be an A-label as defined in IDNA, converted from (and convertible to) a U-label that is consistent with the definition in IDNA, and further restricted by the following, non-exhaustive,
 list of limitations: </span><span style="font-size:11.0pt"><o:p></o:p></span></li></ol>
<p style="margin-left:1.0in"><span style="font-size:10.0pt;font-family:CenturyGothic">2.1.1  Must be a valid A-label according to IDNA.
</span><o:p></o:p></p>
<p style="margin-left:1.0in"><span style="font-size:10.0pt;font-family:CenturyGothic">2.1.2  The derived property value of all codepoints used in the U-label, as defined by IDNA, must be PVALID or CONTEXT (accompanied
</span><o:p></o:p></p>
<p style="margin-left:1.0in"><span style="font-size:10.0pt;font-family:CenturyGothic">2.1.3  The general category of all codepoints, as defined by IDNA, must be one of (Ll, Lo, Lm, Mn, Mc).
</span><o:p></o:p></p>
<p style="margin-left:1.0in"><span style="font-size:10.0pt;font-family:CenturyGothic">2.1.4  The U-label must be fully compliant with Normalization Form C, as described in
<i>Unicode Standard Annex #15: Unicode Normalization Forms. </i>See also examples in
<span style="color:blue"><a href="http://unicode.org/faq/normalization.html">http://unicode.org/faq/normalization.html</a></span>.
</span><o:p></o:p></p>
<p style="margin-left:1.0in"><span style="font-size:10.0pt;font-family:CenturyGothic">2.1.5  The U-label must consist entirely of characters with the same directional property, or fulfill the requirements of the Bidi rule per RFC 5893.
</span><o:p></o:p></p>
<ol start="2" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3">
<span style="font-size:10.0pt;font-family:CenturyGothic">2.2  The label must meet the relevant criteria of the ICANN
<i>Guidelines for the Implementation of Internationalised Domain Names</i>. See <span style="color:blue">
<a href="http://www.icann.org/en/topics/idn/implementation-guidelines.htm">http://www.icann.org/en/topics/idn/implementation-guidelines.htm</a></span>. This includes the following, non- exhaustive, list of limitations:
</span><span style="font-size:11.0pt"><o:p></o:p></span></li></ol>
<p style="margin-left:1.0in"><span style="font-size:10.0pt;font-family:CenturyGothic">2.2.1  All code points in a single label must be taken from the same script as determined by the Unicode Standard Annex #24: Unicode Script Property (See
<span style="color:blue"><a href="http://www.unicode.org/reports/tr24/">http://www.unicode.org/reports/tr24/</a></span>).
</span><o:p></o:p></p>
<p style="margin-left:1.0in"><span style="font-size:10.0pt;font-family:CenturyGothic">2.2.2  Exceptions to 2.2.1 are permissible for languages with established orthographies and conventions that require the commingled use of multiple scripts. However, even
 with this exception, visually confusable characters from different scripts will not be allowed to co-exist in a single set of permissible code points unless a corresponding policy and character table are clearly defined.
</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</body>
</html>