[NCAP-Discuss] Current Status of the NCAP Project

[James Galvin]

Jeff,

I have excerpted a small part of your message to focus my response.

Overall, it is disappointing to me that I have to say I disagree with you on the point of whether or not what we are proposing is better.

It’s also important to note that you were commenting on the recommendations in the current draft and that section of the document is at best an outline at this time, i.e., it is a work in progress.  Therefore, I want to thank you for your comments as they will help the writing team to draft the necessary supporting text.  Of course, if you’d like to contribute text to help the Discussion Group develop its final work product that would be most appreciated!


On 4 Nov 2022, at 16:27, Jeff Schmidt via NCAP-Discuss wrote:

> Four years and 100 meetings later, NCAP hasn't come-up with anything that is demonstrably and objectively better. NCAP's own Study 1 says that.

I consider the following things better.

1. We have added IPv6 support.  Frankly, this was a serious technical gap in the 2012 Controlled Interruption and there was no straightforward way to add it.

2. We have empirically confirmed that the DNS infrastructure and ecosystem has changed dramatically in the past decade and have stated the expert opinion that it is likely to continue to evolve.  Thus, we have created a framework that allows for the evolution of the assessment process, which was an explicit ask of the Board.

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.  As such collision assessment is a risk management problem not an empirical “yes” or “no” decision process.

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.


> What NCAP has come-up with are a bunch of ideas (most previously considered, exhaustively) and a few folks hoping real hard that these ideas will somehow be better. For an unclear definition of better. In fact, the things being considered have real risk of making things worse both procedurally (by creating quagmire and controversy) and technical/operational impacts to the root, root management processes, and to those end-systems experiencing collisions. I get the real sense that some in this group simply don't recognize the diligence applied a decade ago. There were really good reasons we did the things we did in 2012 and no evidence has emerged warranting the types of dangerous schemes being considered.

So let me try to reframe what you are saying here in a positive way.

What we learned in all of our analysis is that there were no flaws or errors or missteps in the prior 2012 analysis.  This is good news.  In fact, we affirmed more convincingly that delegation is required in order to manifest any harm or impact that may result from a name collision.

With this information what we did was evolve the disruptive process used in the 2012 round into two processes: a minimally disruptive one and then a similarly disruptive one.  I happen to think this is an excellent step from a risk management perspective.  Your mileage may vary.

In addition, we have empirical evidence that the “notification mechanism” used in the 2012 round did not work as expected.  Therefore we have evolved the notification mechanism such that the desired goal is more likely to be achieved.  If it doesn’t work I would expect that this will also evolve at some time in the future just as the 2012 round notification is evolving now.

In summary, we have taken the excellent work done to get us the 2012 round proposal, and built on it so it works better in the DNS infrastructure ecosystem we have today, which it turns out is quite different from the ecosystem that existed in 2012.


> Makes zero sense to me. I will likely be submitting a dissenting opinion to be published within NCAP's final work product. Folks interested in contributing to the dissenting opinion please contact me offline.

As a process point, I just want to point out that this Discussion Group will be producing a consensus-based work product, which will not have a section for a dissenting opinion in the main body.  Of course, the work product will be published for public comment and if, at that time, you still believe there is an important dissenting point of view that needs to be included, you should submit a public comment as that will be included in its entirety with the final work product.

Thanks,

Jim