<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=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;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{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;-webkit-nbsp-mode: space;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">I agree with Casey’s comments 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">Everyone – especially the nontechnical people on this list - should take away that there is no clear or perfect solution. It’s all grey with tradeoffs in all directions. Experts disagree. Reasonable people
with wholesome intentions disagree.<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 are also directly competing objectives. In particular, increasing “visibility” and collecting “more data” to perform “more research” by definition creates new security, stability, privacy, and legal/regulatory/compliance
issues not the least of which is managing all these new datasets (vetting researchers, data lifecycle, compliance, etc). These are long-tail obligations that are not cost or risk free.<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’re operating in an extremely brittle technical realm. Negative collision impacts are driven by limited technical understanding and in general people doing things they really shouldn’t be doing. Any and
all assumptions we make about how things will or won’t work are fraught with peril. Principals of conservatism must drive our thinking; this is why I highly value historical experience and resist change without clear and compelling rationale.<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 a question of balancing imperfect solutions.<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 is why I keep coming back to: what problem are we trying to solve? What – specifically – went so horribly wrong in 2012 that we need to accept difficult tradeoffs moving forward? We have never adequately
answered this fundamental question.<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">NCAP-Discuss <ncap-discuss-bounces@icann.org> on behalf of Casey Deccio <casey@deccio.net><br>
<b>Date: </b>Friday, November 11, 2022 at 9:52 AM<br>
<b>To: </b>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>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:white">\</span><span style="font-size:11.0pt">On Nov 10, 2022, at 4:34 AM, James Galvin <<a href="mailto:galvin@elistx.com">galvin@elistx.com</a>> wrote:<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
I consider the following things better.<br>
<br>
1. Frankly, [lack of IPv6 support] was a serious technical gap in the 2012 Controlled Interruption<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<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">It is a fact that controlled interruption does not support IPv6. While I do agree that IPv6 support is *desirable*, I am interested to know why you feel that this is a "serious technical gap". And to be
clear, I'm not talking about the general advancement of IPv6; I'm talking about the goals of controlled interruption. I have taken time to write categories for technical consideration in the comparison doc, among which are the goals for alerting and data
collection. Also in that doc are descriptions of how controlled interruption and the other proposed techniques measure up.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">3. We have stated the expert analysis and conclusion that in today’s DNS infrastructure and ecosystem it is impossible (and I do want to emphasize *impossible*) to fully predict harm or impact without delegation,
and even with any data collection that data collection can *never* be accepted as complete.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<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">There is general agreement that quantitative measures alone cannot accurately assess the impact of name collisions. That is in part why the root cause analysis includes analysis of three qualitative data
sets: the name collisions reports; the survey results; and the Web search results. These are not comprehensive measures, but they do go beyond the speculation of a purely quantitative analysis. And they correlate with the quantitative analysis, yielding
this finding in the root cause analysis:<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">"Name collision reports are supported strongly by measured data."<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">Also proposed (and in progress) is a deeper analysis--both qualitative and quantitative--that goes beyond the scope that I was limited to in the current root cause analysis. So I feel that definitive qualifiers
such as "never" and "impossible" are a bit extreme.<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">Even so, I'm not sure how this is at opposition with controlled interruption? Doesn't controlled interruption involve delegation?<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">As such collision assessment is a risk management problem not an empirical “yes” or “no” decision process.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<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">I have never really understood this statement. And I as I mentioned in Wednesday's call, risk is a very loaded ambiguous term, which I have tried to avoid altogether in the comparison doc and other writings.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">4. We have designed and recommended a minimally disruptive assessment step (PCA) that provides considerable insight into the presence of collisions with a minimal risk of actual harm or impact.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<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">"minimally disruptive" - As was mentioned in the comparison doc, the mailing list, and Wednesday's call, this is an assumption. It's not a bad assumption, in my opinion, but it does change behavior, and without
testing, it's hard to know what might be impacted, how, and to what extent. There are measurements that could be carried out to try to understand this ahead of time, but as far as I have seen, none have been done.<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">"considerable insight" - Expected benefits to the passive collection approach are detailed in the "telemetry" section of the comparison doc. It can increase the fidelity of passive measurements, but 1) these
are still only quantitative measurements, and 2) only analysis of the data will tell us how much better we actually are from traditional passive data collections (e.g., with root data) and how considerable the insights are.<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">Again, while this is an interesting consideration, this is not at odds with controlled interruption.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">In addition, we have empirical evidence that the “notification mechanism” used in the 2012 round did not work as expected.
<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<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">To be clear, I think you are referring to finding 127.0.53.53. Yes, according to the name collision reports and the survey, finding 127.0.53.53 was relatively low. But also, once identified, associating
ICANN was relatively high.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> Therefore we have evolved the notification mechanism such that the desired goal is more likely to be achieved.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<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">I assume you are referring to the communication interception that is active collision assessment? We also have empirical evidence that suggests that the discovery of name collisions with browsers is low.
And the expected user experience associated with active collision in browsers and non-browsers is fraught with issues involving TLS certificate errors, unexpected content, and more--not to mention the privacy concerns.<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">Casey<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>