[NCAP-Discuss] Current Status of the NCAP Project

[Jeff Schmidt]

Hi, Anne:

2012 procedures provably accomplished every objective you listed and with less cost and less risk than the proposed procedures.

> Do you have a better system for accomplishing the
> goals in 1, 2, and 3 above?    In other words, in your
> dissenting opinion that you will write, what is your
> solution?

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

> PCA is a less disruptive method

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)  *will* be sent over the Internet *because of ACA*. Yes, 2012 Controlled Interruption *was* at the time also unknown and untested – but it’s not anymore. We have 1000+ strings and a decade of experience. No one has established a justification to make a risky change.

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.

> it lets applicants "off the hook"

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.

> We need a system in place that identifies the High Risk strings

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.

> Applicants need to be able to propose mitigation

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.

> All of the above is actually different from the 2012 round

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.

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.

> It's designed to give the Board the required info before a contract is awarded.

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.

> dissenting opinion that you will write, what is your solution?

See above. SubPro – in no uncertain terms - cleared us to do what we did in 2012 again. We should take them up on it.

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.

When do we start Study 3?

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221108/c08b0572/attachment.html>