<html 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=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
.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;}
--></style>
</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">Hi, Anne: <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">2012 procedures provably accomplished every objective you listed and with less cost and less risk than the proposed procedures.
<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">> Do you have a better system for accomplishing the
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> goals in 1, 2, and 3 above? In other words, in your
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> dissenting opinion that you will write, what is your
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> solution?<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">(1) Identify “Black Swans” – we did this in 2012 via the “TRT” (which in 2012 was Interisle and JAS). They were hired as technical experts and reviewed all the technical metrics discussed in the NCAP (*and
more*), and based on the data and their expert opinions identified corp, home, and mail as “Black Swan” strings. The remaining strings were deemed safe to delegate, following a CI period. The ensuing decade has proven this to be correct.
</span><span style="font-size:11.0pt">No change necessary or justified.</span><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">> </span><span style="font-size:11.0pt">PCA is a less disruptive method<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">There is nothing about PCA that is “less disruptive” or in any way “safer.” That is false marketing. It is an unknown, untested, and non-standards-compliant procedure and we have no idea what will happen should
we actually do it. Except we know one thing will happen: unknown data (potentially sensitive) *<b>will</b>* be sent over the Internet *<b>because of ACA</b>*. Yes, 2012 Controlled Interruption *<b>was</b>* at the time also unknown and untested –
<i>but it’s not anymore</i>. We have 1000+ strings and a decade of experience. No one has established a justification to make a risky change.<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">Everything about PCA and ACA violates the basic principals of conservatism. The importance of conservatism when adding to the root zone is reflected in Recommendations 26.2 and 26.3, which request ICANN honor
the principle of conservatism specifically wrt limiting the rate of change of the root zone. There is simply no justification to risk *doubling* root zone change events and monkeying with bulk TLD honeypots. We very specifically considered and decided against
this in 2012 for that reason. Juice not worth the squeeze. No change necessary or justified.<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">> it lets applicants "off the hook"<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 is a procedural issue not a technical one. Applicants may be let “off the hook” at any time ICANN permits. Clarity here over 2012 procedures would indeed be an improvement, but again that is procedural
not technical.<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">> We need a system in place that identifies the High Risk strings<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">See #1. We certainly had this in 2012. The 2012 “TRT” reviewed the data and made expert determinations based on all available data. Time has proven them correct. No change necessary or justified.<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">> Applicants need to be able to propose mitigation<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">Agree. And there is no way to handle this other than as a case-by-case. The right way to do this is similar to ICANN’s existing RSTEP program – where a Registry proposes a Registry Service change and technical
experts review it and make an expert determination on a case-by-case basis. In the collisions case, the TRT would review the data and the proposed mitigation and make a determination. There is no magic. Limited TLD honeypots may come into play here – which
is appropriate. A few TLD honeypots for specific strings are justifiable. Thousands of bulk TLD honeypots for every string are not.<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 the above is actually different from the 2012 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">No. It’s all the same as the 2012 round, except for the addition of the unnecessarily complex, expensive, risky, and reckless root delegations and TLD honeypots.
<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 group tends to underappreciate what was done in 2012. I was in the proverbial room where it happened. While the issue of collisions surfaced late in the overall process, once the issue was recognized
it was delt with very deliberately. The resulting 2012 procedures were well-reasoned, extensively vetted, discussed publicly in many fora, subject to multiple ICANN public comment rounds, discussed at multiple conferences/events, DNS-OARC, and even a Verisign
special-purpose event in London. 2012 procedures were lab tested in advance to the greatest degree possible, previewed and discussed with vendors, and in general extremely, extremely, extremely conservative. And 2012 procedures now have the benefit of a decade
of operational experience and vigorous peer review. ACA/PCA is nothing more than old ideas previously rejected now being rekindled by a very few folks hoping real hard that magic will happen.<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">> It's designed to give the Board the required info before a contract is awarded. <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 Board wants experts to make a recommendation. That’s how Boards work. That’s exactly what happened in 2012 and what must happen moving forward. Everything else is just unnecessary complexity, expense,
and risk. No change necessary or justified.<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">> </span><span style="font-size:11.0pt">dissenting opinion that you will write, what is your solution?<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">See above. SubPro – in no uncertain terms - cleared us to do what we did in 2012 again. We should take them up on it.
<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">NCAP has become a self-justifying research project that never ends. The DoD calls dynamics like NCAP a “self-licking ice cream cone” – a system that has no purpose other than to sustain itself.<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">When do we start Study 3?<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>
</div>
</body>
</html>