[NCAP-Discuss] Current Status of the NCAP Project

Sun Nov 13 01:53:57 UTC 2022

A few comments inline.

On 11 Nov 2022, at 10:52, Casey Deccio wrote:

>> \On Nov 10, 2022, at 4:34 AM, James Galvin <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.

A goal of controlled interruption is to work on today’s Internet.  Today’s Internet includes IPv6.  Failing to cover IPv6 increases the risk that controlled interruption will not achieve the goal of manifesting name collisions.  And while the traffic volume of IPv6 may be increasing ever so slowly, whatever that rate is becomes the same rate at which the risk of controlled interruption failing to achieve its goal will also increase.

Thus, on this one key point, both PCA and ACA are vastly superior to controlled interruption.

>
>> 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?

Agreed.  This is why ACA and PCA are just evolved versions of controlled interruption.  We are adopting all of the excellent work done for the 2012 Round, learning some important lessons, discovering some important observations about today’s Internet, and simply evolving controlled interruption ever so slightly so it can continue to be the excellent concept it was in 2012.

>
>> 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.

Our mileage apparently varies.  I’m okay with this.

>
>> 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.

We have over 10 years of experience with post-Controlled Interruption, which is exactly the same configuration as PCA.  Is there something specific you believe we are overlooking?

>
> "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.

Agreed.  That’s why we’re doing it.

>
>> 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.

Agreed.  Do you believe this is misrepresented in the current draft document?  If so, would you please suggest the changes necessary to bring the text in alignment?

>
>>  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.

Agreed.  All of this needs to be included in the document.  Would you be able to contribute some text to make sure we don’t miss anything?

Jim

>
> 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.