[NCAP-Discuss] Current Status of the NCAP Project

[Jeff Schmidt]

> What standards should be used to classify strings as “high risk”?

Note the current NCAP document does not answer this question, other than noting the importance of expert discretion in the “gaming” section. This is exactly the 2012 procedure. And the correct one. Like all the other evaluation panel types, experts must analyze and make recommendations. This isn’t complecting.

> Should there not be a TRT at ICANN?  Should there be a competitive RFP for bidders like JAS and Interisle to do the work again?

Like the other evaluation types (finance, geo, string, etc), ICANN should run a competitive RFP for qualified bidders to implement the TRT. Like it did in 2012. Note that the existing “DNS Stability Review” in the 2012 round could be simply expanded to include collisions. Problem solved. Not complicating.

>  I’d like to see the next round go forward as quickly and smoothly as possible

If that is indeed the case, then you should support making small refinements to a working, proven process – not inventing complex, expensive, and risky new things that will certainly end in quagmire – or worse. Your previous commentary in this group – essentially promoting a zero-risk position – do not support any new TLDs, ever.

Jeff



From: Aikman-Scalese, Anne <AAikman at lewisroca.com>
Date: Tuesday, November 8, 2022 at 5:05 PM
To: Jeff Schmidt <jschmidt at jasadvisors.com>, NCAP Discussion Group <ncap-discuss at icann.org>
Subject: RE: [NCAP-Discuss] Current Status of the NCAP Project
Thanks Jeff.  What standards should be used to classify strings as “high risk”?  Should there not be a TRT at ICANN?  Should there be a competitive RFP for bidders like JAS and Interisle to do the work again?  Will the contractors hired by ICANN be using the same standards of risk assessment?  Or would only one contractor be awarded the business?  Who will specify the factors to be taken into account in the analysis?

There are so many references to the 2012 procedure below, but as I understand it, the work the DG has been trying to accomplish is to standardize procedures and I’m not seeing that in your recap of what happened in 2012.  The 2012 Name Collision Assessment Framework just says corp, home, and mail are “disallowed” and after that (if Alternate Path to Delegation was not used) then just use  90-day Controlled Interruption.  So the existing Framework doesn’t actually cover all the steps that you state below and doesn’t cover the assessment of high risk strings as a standardized procedure.

As you know, and as recited in the background section of draft Study 2, a number of goals listed in the Sub Pro Final Report involved a standardized system.  The Recommendations included asking ICANN to develop a method for identifying High Risk strings in advance of the next round.  Some in NCAP may say they want to just “fallback” on the Sub Pro Plan B recommendation if no new system is developed and adopted by the Board but no one in the DG actually proposed a written methodology for the steps you describe.  If that had actually been done, we might be farther along.  Said another way, how would you change the chart that shows the four “off-ramps” for Applicants as it appears in the draft Study 2 report?  Can we see your proposed chart?

I don’t think “Do what you did in 2012” is an adequate answer to creating a standardized procedure for the Board to adopt.    (I am not commenting on the technical aspects of PCA and ACA here.)  I’ll also reiterate that both the GAC and ALAC are on record as opposing a next round going forward until there is a standardized new name collision framework in place.  In particular, in previous correspondence,  the GAC pointed out certain aspects of the Sub Pro Recommendations on Name Collisions that it is looking to see happen.  I previously sent those GAC comments to this list but some seem to think they should be ignored.  As you know (and again as I have repeated so many times, when the GAC provides consensus advice to the Board, it has a significant effect under the ByLaws and the Board usually kicks the issue back to the community if the GAC and the GNSO don’t agree.  The Board says, “we don’t make policy” and asks the parties to go “work it out.”)  My view is that anyone who thinks the GAC won’t provide consensus advice on this name collisions issue is engaging in wishful thinking.  It is also noted that GAC and ALAC are working very closely together at this point in time on many issues.

Trying to bulldoze the fallback position of the Sub Pro WG through this process is not a viable strategy and will delay the next round.  A written proposal that standardizes all the procedures you advocate might help move the ball forward if it takes into account previous GAC and ALAC comments.  Then it would need to be endorsed by SSAC, which is the body responsible for answering the Board’s questions about name collisions.    I’d like to see the next round go forward as quickly and smoothly as possible but the IDN WG is apparently looking at delivering Phase II in relation to second level idn names sometime in the fall of 2025.

Any chance your “dissenting view” could actually propose a written standardized system that addresses the actual Sub Pro Recommendations that the GAC pointed out in previous correspondence?  Jeff Neuman is intimately familiar with these and is a good writer.  Based on discussions held previously in Sub Pro, I’m sure he and Rubens will be happy to jump on the bandwagon but I can’t see the Board moving forward on something that ignores what has been and will ultimately be coming from the GAC and ALAC.  This is ICANN’s weakest point in organizational effectiveness – the inability of the community to reconcile differences of opinion before they get to the Board.

Sub Pro Recommendation 1 says ICANN MUST develop a Name Collision Risk Assessment methodology prior to the next round.  “Let’s do what we did in 2012” does not describe a methodology and can’t really be effectively adopted by the Board, particularly not when standing GAC and ALAC advice is asking for more.

Anne



Anne E. Aikman-Scalese
Of Counsel

AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>
D. 520.629.4428
[cid:image002.png at 01D8F388.70A40990]

From: Jeff Schmidt <jschmidt at jasadvisors.com>
Sent: Tuesday, November 8, 2022 1:14 PM
To: Aikman-Scalese, Anne <AAikman at lewisroca.com>; NCAP Discussion Group <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Current Status of the NCAP Project

[EXTERNAL]
________________________________
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


________________________________

This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221108/c37c82ae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 224 bytes
Desc: image001.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221108/c37c82ae/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2031 bytes
Desc: image002.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221108/c37c82ae/image002-0001.png>