<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)">
<!--[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;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle21
{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;}
--></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">Jeff,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">These answers don’t reflect the reality that a standardized written procedure is required.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Anne<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><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%"><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%"><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"><img width="17" height="7" style="width:.1736in;height:.0763in" id="_x0000_i1033" src="cid:image001.png@01D8F38F.CFBA36F0"></span><span style="font-size:11.0pt;line-height:106%"><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="line-height:106%;font-family:"Trebuchet MS",sans-serif"><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%"><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="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%"><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="line-height:106%;font-family:"Trebuchet MS",sans-serif"><img border="0" width="160" height="22" style="width:1.6666in;height:.2291in" id="_x0000_i1032" src="cid:image002.png@01D8F38F.CFBA36F0"></span><span style="font-size:11.0pt;line-height:106%"><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"><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"> Jeff Schmidt <jschmidt@jasadvisors.com>
<br>
<b>Sent:</b> Tuesday, November 8, 2022 4:29 PM<br>
<b>To:</b> Aikman-Scalese, Anne <AAikman@lewisroca.com>; NCAP Discussion Group <ncap-discuss@icann.org><br>
<b>Subject:</b> Re: [NCAP-Discuss] Current Status of the NCAP Project<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><strong><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:black">[EXTERNAL]</span></strong><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:black"><o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:11.0pt">
<hr size="2" width="100%" align="center">
</span></div>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">> What standards should be used to classify strings as “high risk”?
<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">Note the current NCAP document does not answer this question, other than noting the importance of expert discretion in the “gaming” section. This is exactly the 2012 procedure. And the correct one. Like all
the other evaluation panel types, experts must analyze and make recommendations. This isn’t complecting.<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">> Should there not be a TRT at ICANN? Should there be a competitive RFP for bidders like JAS and Interisle to do the work again?<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">Like the other evaluation types (finance, geo, string, etc), ICANN should run a competitive RFP for qualified bidders to implement the TRT. Like it did in 2012. Note that the existing “DNS Stability Review”
in the 2012 round could be simply expanded to include collisions. Problem solved. Not complicating.<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’d like to see the next round go forward as quickly and smoothly as possible<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">If that is indeed the case, then you should support making small refinements to a working, proven process – not inventing complex, expensive, and risky new things that will certainly end in quagmire – or worse.
Your previous commentary in this group – essentially promoting a zero-risk position – do not support any new TLDs, ever.<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>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<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">Aikman-Scalese, Anne <<a href="mailto:AAikman@lewisroca.com">AAikman@lewisroca.com</a>><br>
<b>Date: </b>Tuesday, November 8, 2022 at 5:05 PM<br>
<b>To: </b>Jeff Schmidt <<a href="mailto:jschmidt@jasadvisors.com">jschmidt@jasadvisors.com</a>>, NCAP Discussion Group <<a href="mailto:ncap-discuss@icann.org">ncap-discuss@icann.org</a>><br>
<b>Subject: </b>RE: [NCAP-Discuss] Current Status of the NCAP Project<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks Jeff. What standards should be used to classify strings as “high risk”? Should there not be a TRT at ICANN? Should there be a competitive RFP for bidders like JAS and Interisle to do the work again?
Will the contractors hired by ICANN be using the same standards of risk assessment? Or would only one contractor be awarded the business? Who will specify the factors to be taken into account in the analysis?
</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">There are so many references to the 2012 procedure below, but as I understand it, the work the DG has been trying to accomplish is to standardize procedures and I’m not seeing that in your recap of what happened
in 2012. The 2012 Name Collision Assessment Framework just says corp, home, and mail are “disallowed” and after that (if Alternate Path to Delegation was not used) then just use 90-day Controlled Interruption. So the existing Framework doesn’t actually
cover all the steps that you state below and doesn’t cover the assessment of high risk strings as a standardized procedure.
</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">As you know, and as recited in the background section of draft Study 2, a number of goals listed in the Sub Pro Final Report involved a standardized system. The Recommendations included asking ICANN to develop
a method for identifying High Risk strings in advance of the next round. Some in NCAP may say they want to just “fallback” on the Sub Pro Plan B recommendation if no new system is developed and adopted by the Board but no one in the DG actually proposed a
written methodology for the steps you describe. If that had actually been done, we might be farther along. Said another way, how would you change the chart that shows the four “off-ramps” for Applicants as it appears in the draft Study 2 report? Can we
see your proposed chart?</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">I don’t think “Do what you did in 2012” is an adequate answer to creating a standardized procedure for the Board to adopt. (I am not commenting on the technical aspects of PCA and ACA here.) I’ll also
reiterate that both the GAC and ALAC are on record as opposing a next round going forward until there is a standardized new name collision framework in place. In particular, in previous correspondence, the GAC pointed out certain aspects of the Sub Pro Recommendations
on Name Collisions that it is looking to see happen. I previously sent those GAC comments to this list but some seem to think they should be ignored. As you know (and again as I have repeated so many times, when the GAC provides consensus advice to the Board,
it has a significant effect under the ByLaws and the Board usually kicks the issue back to the community if the GAC and the GNSO don’t agree. The Board says, “we don’t make policy” and asks the parties to go “work it out.”) My view is that anyone who thinks
the GAC won’t provide consensus advice on this name collisions issue is engaging in wishful thinking. It is also noted that GAC and ALAC are working very closely together at this point in time on many issues.</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">Trying to bulldoze the fallback position of the Sub Pro WG through this process is not a viable strategy and will delay the next round. A written proposal that standardizes all the procedures you advocate
might help move the ball forward if it takes into account previous GAC and ALAC comments. Then it would need to be endorsed by SSAC, which is the body responsible for answering the Board’s questions about name collisions. I’d like to see the next round
go forward as quickly and smoothly as possible but the IDN WG is apparently looking at delivering Phase II in relation to second level idn names sometime in the fall of 2025.</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">Any chance your “dissenting view” could actually propose a written standardized system that addresses the actual Sub Pro Recommendations that the GAC pointed out in previous correspondence? Jeff Neuman is
intimately familiar with these and is a good writer. Based on discussions held previously in Sub Pro, I’m sure he and Rubens will be happy to jump on the bandwagon but I can’t see the Board moving forward on something that ignores what has been and will ultimately
be coming from the GAC and ALAC. This is ICANN’s weakest point in organizational effectiveness – the inability of the community to reconcile differences of opinion before they get to the Board.</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">Sub Pro Recommendation 1 says ICANN
<b>MUST</b> develop a Name Collision Risk Assessment methodology prior to the next round. “Let’s do what we did in 2012” does not describe a methodology and can’t really be effectively adopted by the Board, particularly not when standing GAC and ALAC advice
is asking for more.</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">Anne</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"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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:105%"><b><span style="font-size:11.0pt;line-height:105%;font-family:"Trebuchet MS",sans-serif;color:#323232">Anne E. Aikman-Scalese</span></b><o:p></o:p></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:105%"><span style="font-size:11.0pt;line-height:105%;font-family:"Trebuchet MS",sans-serif;color:#323232">Of Counsel</span><o:p></o:p></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:105%"><span style="font-size:11.0pt;line-height:105%;font-family:"Trebuchet MS",sans-serif;color:#323232"><img border="0" width="17" height="7" style="width:.1736in;height:.0694in" id="Picture_x0020_2" src="cid:image001.png@01D8F38F.CFBA36F0"></span><o:p></o:p></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:105%"><span style="font-family:"Trebuchet MS",sans-serif"><a href="mailto:AAikman@lewisroca.com" target="_new" title="Email User"><span style="color:#323232">AAikman@lewisroca.com</span></a></span><o:p></o:p></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:105%"><span style="font-family:"Trebuchet MS",sans-serif;color:#323232">D. 520.629.4428</span><o:p></o:p></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:105%"><span style="font-family:"Trebuchet MS",sans-serif"><img border="0" width="160" height="22" style="width:1.6666in;height:.2291in" id="Picture_x0020_1" src="cid:image002.png@01D8F38F.CFBA36F0"></span><o:p></o:p></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"> </span><o:p></o:p></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"> Jeff Schmidt <<a href="mailto:jschmidt@jasadvisors.com">jschmidt@jasadvisors.com</a>>
<br>
<b>Sent:</b> Tuesday, November 8, 2022 1:14 PM<br>
<b>To:</b> Aikman-Scalese, Anne <<a href="mailto:AAikman@lewisroca.com">AAikman@lewisroca.com</a>>; NCAP Discussion Group <<a href="mailto:ncap-discuss@icann.org">ncap-discuss@icann.org</a>><br>
<b>Subject:</b> Re: [NCAP-Discuss] Current Status of the NCAP Project</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><strong><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:black">[EXTERNAL]</span></strong><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:11.0pt">
<hr size="1" width="100%" align="center">
</span></div>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi, Anne: </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">2012 procedures provably accomplished every objective you listed and with less cost and less risk than the proposed procedures.
</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">> Do you have a better system for accomplishing the
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> goals in 1, 2, and 3 above? In other words, in your
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> dissenting opinion that you will write, what is your
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> solution?</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">(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. No change necessary
or justified.</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">> PCA is a less disruptive method</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">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.</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">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.</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">> it lets applicants "off the hook"</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">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.</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">> We need a system in place that identifies the High Risk strings</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">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.</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">> Applicants need to be able to propose mitigation</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">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.</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">> All of the above is actually different from the 2012 round</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">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.
</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">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.</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">> It's designed to give the Board the required info before a contract is awarded. </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 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.</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">> dissenting opinion that you will write, what is your solution?</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">See above. SubPro – in no uncertain terms - cleared us to do what we did in 2012 again. We should take them up on it.
</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">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.</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">When do we start Study 3?</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">Jeff</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"><o:p> </o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:11.0pt">
<hr size="1" width="100%" align="center">
</span></div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:gray"><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.
</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</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>