<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=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">I did not realize that Study 2 was split into 2 separate documents. In the second doc, I see:<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">> Finding B.c: It is impractical to create a do-not-apply list of strings in advance of new requests for delegation<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">Which directly answers my question below.<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"><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">However, I also noticed:
<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">> 5.5 Recommendation 5 - ICANN must support the delegation of strings in order to improve the ability to conduct a name collision risk assessment<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">Noting this is a “must” and we have not addressed the IANA/root size issue (at all) is a problem.<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">This would also put us in direct conflict with SubPro:<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">Recommendation 26.2: ICANN must honor and review the principle of conservatism when adding new gTLDs to the root zone.
<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">Recommendation 26.3: ICANN must focus on the rate of change for the root zone over smaller periods of time (e.g., monthly) rather than the total number of delegated strings for a given calendar year.
<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">Implementation Guidance 26.4: The number of TLDs delegated in the root zone should not increase by more than approximately 5 percent per month, with the understanding that there may be minor variations from
time-to-time.<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jeff<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"><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"> NCAP-Discuss <ncap-discuss-bounces@icann.org>
<b>On Behalf Of </b>Jeff Schmidt via NCAP-Discuss<br>
<b>Sent:</b> Thursday, September 7, 2023 10:42 AM<br>
<b>To:</b> Rubens Kuhl <rubensk@nic.br>; ncap-discuss@icann.org<br>
<b>Subject:</b> Re: [NCAP-Discuss] "Do Not Apply"<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">Agree. But since it’s Guidance ICANN needs to either follow it or explain why not. NCAP can’t be slient.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">NCAP-Discuss <</span><a href="mailto:ncap-discuss-bounces@icann.org"><span style="font-size:12.0pt">ncap-discuss-bounces@icann.org</span></a><span style="font-size:12.0pt;color:black">> on behalf of Rubens
Kuhl via NCAP-Discuss <</span><a href="mailto:ncap-discuss@icann.org"><span style="font-size:12.0pt">ncap-discuss@icann.org</span></a><span style="font-size:12.0pt;color:black">><br>
<b>Date: </b>Thursday, September 7, 2023 at 10:12 AM<br>
<b>To: </b></span><a href="mailto:ncap-discuss@icann.org"><span style="font-size:12.0pt">ncap-discuss@icann.org</span></a><span style="font-size:12.0pt;color:black"> <</span><a href="mailto:ncap-discuss@icann.org"><span style="font-size:12.0pt">ncap-discuss@icann.org</span></a><span style="font-size:12.0pt;color:black">><br>
<b>Subject: </b>Re: [NCAP-Discuss] "Do Not Apply"<o:p></o:p></span></p>
</div>
<div>
<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">Jeff,<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">In SubPro lingo, an Implementation Guidance is akin to a SHOULD in BCP 14. So lack of an NCAP position on it won’t make ICANN Org to have to do it… it’s not a MUST. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">That said, there would be no harm in having that specified by NCAP. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Rubens<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Em 7 de set. de 2023, à(s) 11:52, Jeff Schmidt via NCAP-Discuss <</span><a href="mailto:ncap-discuss@icann.org"><span style="font-size:11.0pt">ncap-discuss@icann.org</span></a><span style="font-size:11.0pt">>
escreveu:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Team:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">SubPro said:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Implementation Guidance 29.3: To the extent possible, ICANN should seek to identify high-risk strings in advance of opening the Application Submission Period, which should constitute a “Do Not Apply” list.
ICANN should also seek to identify aggravated risk strings in advance of the next application window opening and whether it would require a specific name collision mitigation framework.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">We (NCAP) have talked quite a bit about the difficulties of an a-priori collisions “Do Not Apply” list. I “think” we are all in agreement that such a list cannot be produced, however such assumptions are dangerous.
I looked in Study 1 and the draft of Study 2 and they are both, surprisingly, silent on the NCAP position on “Do Not Apply.”<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Is there consensus that NCAP will state that a-priori “Do Not Apply" is not possible? If so, this should be included in Study 2. If not, uhm, add it to the discussion list.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks!<br>
Jeff<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
NCAP-Discuss mailing list<br>
</span><a href="mailto:NCAP-Discuss@icann.org"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">NCAP-Discuss@icann.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://mm.icann.org/mailman/listinfo/ncap-discuss"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">https://mm.icann.org/mailman/listinfo/ncap-discuss</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (</span><a href="https://www.icann.org/privacy/policy"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">https://www.icann.org/privacy/policy</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">)
and the website Terms of Service (</span><a href="https://www.icann.org/privacy/tos"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">https://www.icann.org/privacy/tos</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">).
You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>