<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: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;}
@font-face
{font-family:"Trebuchet MS";
panose-1:2 11 6 3 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
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;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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:450319745;
mso-list-type:hybrid;
mso-list-template-ids:-278864542 -1573341268 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"\(%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Jeff and Rubens,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Having participated actively in Sub Pro, I am not surprised by the approach you have both taken in your comments, though they do seem to be a bit “late-breaking”
in terms of the process the DG has been following. The Workflow document has been around for a long time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’ll also note that Sub Pro Recommendations in the Final Report (adopted by the GNSO Council and sent to the ICANN Board) state that
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span style="mso-list:Ignore">(1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">ICANN should develop a DO NOT APPLY list for names that have too great a risk of potential harm. (The potential harms were identified in NCAP Study
1).<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span style="mso-list:Ignore">(2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Any New Name Collision Framework coming out of the NCAP process and recommended to the Board by SSAC (which is adopted by the Board in time for the
next round) should govern. Considering the projected time frame for the ODP, there should be ample time for this process to “dovetail” the development of an AGB. And the ODP notes that this issue of a possible new Name Collision Framework has to be resolved.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Reports of name collision issues to ICANN based on the 2012 round and the “lack of litigation” in this realm is not a reliable measure for answering the issues
raised by NCAP Study 1 or the Board’s specific questions to the SSAC on this topic. Those Board questions have been guiding the work of the DG for months and there is also recognition that the DNS is not static.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I don’t think NCAP DG is a forum designed to revisit the policy work already done in Sub Pro and the Recommendations that came out of that process. And I don’t
think the NCAP DG can ignore the specific questions posed by the Board and the results of Study 1 by simply saying – “well, it seems to us it all went just fine in the 2012 round.”
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Anne<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr>
<td width="336" valign="top" style="width:3.5in;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="line-height:106%"><b><span style="font-size:11.0pt;line-height:106%;font-family:"Trebuchet MS",sans-serif;color:#323232">Anne E. Aikman-Scalese</span></b><span style="font-size:11.0pt;line-height:106%;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="336" valign="top" style="width:3.5in;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="margin-bottom:3.0pt;line-height:106%"><span style="font-size:11.0pt;line-height:106%;font-family:"Trebuchet MS",sans-serif;color:#323232">Of Counsel</span><span style="font-size:11.0pt;line-height:106%;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="336" valign="top" style="width:3.5in;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="margin-bottom:3.0pt;line-height:40%"><span style="font-size:10.0pt;line-height:40%;font-family:"Trebuchet MS",sans-serif;color:#1F497D"><img width="17" height="7" style="width:.1805in;height:.0763in" id="Picture_x0020_2" src="cid:image002.png@01D8232B.0CE50090"></span><span style="font-size:11.0pt;line-height:40%;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="336" valign="top" style="width:3.5in;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="line-height:106%"><span style="font-size:10.0pt;line-height:106%;font-family:"Trebuchet MS",sans-serif;color:#1F497D"><a href="mailto:AAikman@lewisroca.com" target="_new" title="Email User"><span style="color:#323232">AAikman@lewisroca.com</span></a></span><span style="font-size:11.0pt;line-height:106%;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="336" valign="top" style="width:3.5in;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="margin-bottom:.25in;line-height:106%"><span style="font-size:10.0pt;line-height:106%;font-family:"Trebuchet MS",sans-serif;color:#323232">D. 520.629.4428</span><span style="font-size:11.0pt;line-height:106%;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="336" valign="top" style="width:3.5in;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="line-height:106%"><span style="font-size:10.0pt;line-height:106%;font-family:"Trebuchet MS",sans-serif;color:#1F497D"><img border="0" width="160" height="22" style="width:1.6666in;height:.2291in" id="Picture_x0020_1" src="cid:image003.png@01D82329.4578B700"></span><span style="font-size:11.0pt;line-height:106%;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="336" valign="top" style="width:3.5in;padding:0in 5.4pt 0in 5.4pt"></td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><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;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> NCAP-Discuss <ncap-discuss-bounces@icann.org>
<b>On Behalf Of </b>Rubens Kuhl via NCAP-Discuss<br>
<b>Sent:</b> Wednesday, February 16, 2022 11:18 AM<br>
<b>To:</b> ncap-discuss@icann.org<br>
<b>Subject:</b> Re: [NCAP-Discuss] Reflecting on the 'big picture' and making our outputs helpful to the Community<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Besides agreeing wholeheartedly with Jeff, I will just add that this rehashing of old ideas is a good part of the paralysis disease plaguing ICANN (Org + Community) at this point. <o:p></o:p></p>
<div>
<p class="MsoNormal">But name collisions has been used in the past to stall this same root zone expansion program, so this is not a new script, just a new episode of the series. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Rubens<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 16 Feb 2022, at 13:25, Jeff Schmidt via NCAP-Discuss <<a href="mailto:ncap-discuss@icann.org">ncap-discuss@icann.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Team:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">TL;DR:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We should start by recognizing the effectiveness of the 2012 procedures (as codified in the 2014 Name Collision Occurrence Management
Framework)[1] and make surgical improvements for predictability as suggested by SubPro. We should not invent new procedures that introduce enormous and unnecessary new costs, risks, and uncertainty in exchange for unclear value. Our recommendations must be
supported by a sober cost-benefit analysis.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Long Version:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I am responding to the 9 Feb meeting minutes, the “Workflow” slides, and indirectly the recent exchange of letters between the
RySG and the ICANN Board. We need to take note of the recent exchange of letters as it speaks to the importance of providing high-quality, succinct, practical, and actionable advice to the Board. Emphasis on practical and actionable.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Collisions are well understood.</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We
know under what circumstances they occur, and we have real, practical, global-scale operational experience and data after delegating > 1,200 TLDs over the past decade.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Study 1 provides an excellent summary of the enormous amount of thought and data that has been assembled over the past 25 years
regarding collisions. We must ask ourselves the hard question: what are we really adding at this point? We can create new charts and graphs, but the phenomenon remains the same. It is well understood. There isn’t much to add. I have yet to see evidence to
the contrary. We have reached the threshold of analysis paralysis and ambled over it.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We must be aware of and equipped to encounter another “.corp” but not fall into the sensationalist trap that every new TLD
is a disaster waiting to happen. The numbers and the history simply don’t support this FUD (Fear, Uncertainty, and Doubt).</span></i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I am very concerned that in failing to overtly recognize these realities, perpetuating calls for “more data!” and “more research!”
and esoteric academic debate that is accessible and of interest to only a very few, we are at risk of providing unhelpful and/or unimplementable advice to the Board that is indeed “ambiguous, incomplete, or unclear” (reference from Botterman-to-Demetriou).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">What was done in 2012 worked</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">. I would encourage
everyone to look at the Name Collision Reports data and Figure 1 in Study 1 and attempt to convince themselves otherwise.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Study 1 summarizes: “The vast majority of new TLDs delegated since July 2014 have not been the subject of any name collision
reports to ICANN” and “Of all the reports to ICANN, only one led to action by a registry.” There were no contemporaneous large-scale technical/operational problems, no litigation, and in the decade following widespread use of the 2012 procedures no evidence
they caused harm and some evidence they were effective. A decade following the largest changes to the root in the History of the Internet and the attention of more technical experts than you can fit shoulder-to-shoulder in Oklahoma, this is not “absence of
evidence” but rather “evidence of absence.” If this isn’t success, then what is? What specific problems are left to solve?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We should tweak 2012 procedures.</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
strongly feel that an upfront and deliberate discussion of the null hypothesis (do exactly what was done in 2012) would help better communicate our story and recommendations in a practical and actionable manner to the broad audience. There should be a high
bar to recommend changes to procedures that largely worked by any reasonable definition of “worked.” <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">There should be a strong bias to “not break what isn’t broken” and a very high bar to invent new, risky, unproven, and expensive
procedures with unclear value. When we are recommending implementation of a new procedure, it should be against a clear and compelling cost-benefit analysis not mere intellectual curiosity.<span class="apple-converted-space"> </span><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Moreover, we cannot simply ignore the realities of the increasing Balkanization of global privacy frameworks in Europe, Brazil,
and in an increasing number of U.S. States to name a few – and their associated expense and risk. Any recommendation we make to the Board must not invite the kind of risk, expense, and frankly embarrassment ICANN was delt while debating WHOIS with the EU.
ICANN’s “yes but we have really good wholesome reasons!” arguments largely fell on deaf ears with EU regulators and courts ending badly for ICANN; anything we recommend that invites that risk is impractical and a non-starter. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">There is no perfect answer to the collisions issue, but with the exception of the predictability issues that plagued the 2012
round, I have yet to see a shred of evidence that would lead a reasonable person to believe that we can materially improve on what was done previously.<span class="apple-converted-space"> </span><i>The counter risk is apropos: we can certainly make it much,
much worse.</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">“Enhanced Controlled Interruption” is a rebranded Honeypot.</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
don’t understand why we keep celebrating Groundhog Day by rehashing this same tired concept – it’s a terrible idea for all the reasons stated previously. It’s not just me saying this: <span class="apple-converted-space"> </span><i>“Verisign maintains its position
that directing requesters to an internal address during the controlled interruption period is preferable to an external honeypot, because as previously stated, it avoids “controlled exfiltration” where sensitive traffic from an installed system – without the
advance consent of the user or system administrator – may be drawn outside the local network.” [2]</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The biggest problem to solve is the one of predictability (or lack thereof).</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">In
2012, the collisions issue was not covered in pre-application procedures/documentation and unfortunately “sprung” on applicants late in the process. This caused applicants to face many delays and unknowns.<span class="apple-converted-space"> </span><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">As for the “Workflow” slides and the process they suggest, I have major concerns:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">(a) It places the enormous burden of evaluating and mitigating collision risk on the applicant a-priori, something this group
discussed and rejected last year as uneven, ripe for abuse and gaming, expensive, burdensome, and fundamentally impossible;<span class="apple-converted-space"> </span><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">(b) it uses honeypots rebranded as “enhanced controlled interruption” which is a practical nonstarter adding material (and likely
insurmountable) risk and cost for no clear value;<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">(c) creates operational risk and costs by performing multiple delegations and re-delegations at the root per applied-for string
with no clear value;<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">(d) suggests string-wise “mitigation proposals” and “remediation proposals” which are undefined, impossible to evaluate, will
be enormously expensive given the liability implications, and unnecessary in nearly all cases;<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">(e) suggests a number of steps that simply create more data for which analysis is fundamentally subjective and open-ended and
will require enormous resources in terms of both time and cost and add tremendous uncertainty, gamesmanship, and litigation risk; and<span class="apple-converted-space"> </span><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">(f) kicks the can to “the Board” to make several *per-string* decisions along the way with little in the way of frameworks or
guidance - inviting litigation and other (expensive, high risk) conflict that was successfully avoided in 2012 by specifically avoiding all but three string-wise Board decisions.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">While many of us (myself included) find collisions intellectually interesting, we must avoid the temptation to “do more stuff”
because it’s interesting and instead focus on providing succinct, practical, and implementable guidance to the Board. A decade later, there is no evidence to indicate that material improvements can be made to the 2012 procedures without also introducing material
new costs and risks, so we should state that and make surgical improvements. Don’t break what isn’t broken. Don’t trade the tested and familiar – albeit imperfect – for high-risk, unknown, unproven, impractical, and in many cases unimplementable science experiments.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Jeff<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">[1]<span class="apple-converted-space"> </span><a href="https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf"><span style="color:#0563C1">https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf</span></a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">[2]<span class="apple-converted-space"> </span><a href="https://itp.cdn.icann.org/en/files/name-collision/report-comments-name-collision-10jun14-en.pdf"><span style="color:#0563C1">https://itp.cdn.icann.org/en/files/name-collision/report-comments-name-collision-10jun14-en.pdf</span></a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:11.55pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<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;color:#0563C1">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;color:#0563C1">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;color:#0563C1">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;color:#0563C1">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><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message
or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying
to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
<br>
</font>
</body>
</html>