[NCAP-Discuss] Current Status of the NCAP Project

Sun Nov 13 01:56:55 UTC 2022

One comment in line.

On 11 Nov 2022, at 14:58, Jeff Schmidt via NCAP-Discuss wrote:

> I agree with Casey’s comments below.
>
> 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.
>
> 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.
>
> 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.
>
> It’s a question of balancing imperfect solutions.
>
> 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.

The problem we are trying to solve is assessing name collisions in the Internet of today, and tomorrow.  Nothing went wrong in 2012.  What specific difficult tradeoffs do you believe are being made?

We have adopted controlled interruption and added a few straightforward evolutionary changes so it can be effective in today’s Internet.

What specific fundamental question have we not answered?

Jim

>
> Jeff
>
>
>
> From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Casey Deccio <casey at deccio.net>
> Date: Friday, November 11, 2022 at 9:52 AM
> To: NCAP Discussion Group <ncap-discuss at icann.org>
> Subject: Re: [NCAP-Discuss] Current Status of the NCAP Project
> \On Nov 10, 2022, at 4:34 AM, James Galvin <galvin at elistx.com<mailto:galvin at elistx.com>> wrote:
>
> I consider the following things better.
>
> 1. Frankly, [lack of IPv6 support] was a serious technical gap in the 2012 Controlled Interruption
>
> 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.
>
> 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.
>
> 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:
>
> "Name collision reports are supported strongly by measured data."
>
> 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.
>
> Even so, I'm not sure how this is at opposition with controlled interruption?  Doesn't controlled interruption involve delegation?
>
>
> As such collision assessment is a risk management problem not an empirical “yes” or “no” decision process.
>
> 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.
>
>
> 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.
>
> "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.
>
> "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.
>
> Again, while this is an interesting consideration, this is not at odds with controlled interruption.
>
>
> In addition, we have empirical evidence that the “notification mechanism” used in the 2012 round did not work as expected.
>
> 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.
>
>
>  Therefore we have evolved the notification mechanism such that the desired goal is more likely to be achieved.
>
> 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.
>
> Casey

> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.