[NCAP-Discuss] Reflecting on the 'big picture' and making our outputs helpful to the Community

[Jeff Schmidt]

Team:

TL;DR:
We should start by recognizing the effectiveness of the 2012 procedures (as codified in the 2014 Name Collision Occurrence Management Framework)[1] and make surgical improvements for predictability as suggested by SubPro. We should not invent new procedures that introduce enormous and unnecessary new costs, risks, and uncertainty in exchange for unclear value. Our recommendations must be supported by a sober cost-benefit analysis.

Long Version:
I am responding to the 9 Feb meeting minutes, the "Workflow" slides, and indirectly the recent exchange of letters between the RySG and the ICANN Board. We need to take note of the recent exchange of letters as it speaks to the importance of providing high-quality, succinct, practical, and actionable advice to the Board. Emphasis on practical and actionable.
Collisions are well understood. We know under what circumstances they occur, and we have real, practical, global-scale operational experience and data after delegating > 1,200 TLDs over the past decade.
Study 1 provides an excellent summary of the enormous amount of thought and data that has been assembled over the past 25 years regarding collisions. We must ask ourselves the hard question: what are we really adding at this point? We can create new charts and graphs, but the phenomenon remains the same. It is well understood. There isn't much to add. I have yet to see evidence to the contrary. We have reached the threshold of analysis paralysis and ambled over it.
We must be aware of and equipped to encounter another ".corp" but not fall into the sensationalist trap that every new TLD is a disaster waiting to happen. The numbers and the history simply don't support this FUD (Fear, Uncertainty, and Doubt).
I am very concerned that in failing to overtly recognize these realities, perpetuating calls for "more data!" and "more research!" and esoteric academic debate that is accessible and of interest to only a very few, we are at risk of providing unhelpful and/or unimplementable advice to the Board that is indeed "ambiguous, incomplete, or unclear" (reference from Botterman-to-Demetriou).
What was done in 2012 worked. I would encourage everyone to look at the Name Collision Reports data and Figure 1 in Study 1 and attempt to convince themselves otherwise.
Study 1 summarizes: "The vast majority of new TLDs delegated since July 2014 have not been the subject of any name collision reports to ICANN" and "Of all the reports to ICANN, only one led to action by a registry."  There were no contemporaneous large-scale technical/operational problems, no litigation, and in the decade following widespread use of the 2012 procedures no evidence they caused harm and some evidence they were effective. A decade following the largest changes to the root in the History of the Internet and the attention of more technical experts than you can fit shoulder-to-shoulder in Oklahoma, this is not "absence of evidence" but rather "evidence of absence." If this isn't success, then what is? What specific problems are left to solve?
We should tweak 2012 procedures. I strongly feel that an upfront and deliberate discussion of the null hypothesis (do exactly what was done in 2012) would help better communicate our story and recommendations in a practical and actionable manner to the broad audience. There should be a high bar to recommend changes to procedures that largely worked by any reasonable definition of "worked."
There should be a strong bias to "not break what isn't broken" and a very high bar to invent new, risky, unproven, and expensive procedures with unclear value. When we are recommending implementation of a new procedure, it should be against a clear and compelling cost-benefit analysis not mere intellectual curiosity.
Moreover, we cannot simply ignore the realities of the increasing Balkanization of global privacy frameworks in Europe, Brazil, and in an increasing number of U.S. States to name a few - and their associated expense and risk. Any recommendation we make to the Board must not invite the kind of risk, expense, and frankly embarrassment ICANN was delt while debating WHOIS with the EU. ICANN's "yes but we have really good wholesome reasons!" arguments largely fell on deaf ears with EU regulators and courts ending badly for ICANN; anything we recommend that invites that risk is impractical and a non-starter.
There is no perfect answer to the collisions issue, but with the exception of the predictability issues that plagued the 2012 round, I have yet to see a shred of evidence that would lead a reasonable person to believe that we can materially improve on what was done previously. The counter risk is apropos: we can certainly make it much, much worse.
"Enhanced Controlled Interruption" is a rebranded Honeypot. I don't understand why we keep celebrating Groundhog Day by rehashing this same tired concept - it's a terrible idea for all the reasons stated previously. It's not just me saying this:  "Verisign maintains its position that directing requesters to an internal address during the controlled interruption period is preferable to an external honeypot, because as previously stated, it avoids "controlled exfiltration" where sensitive traffic from an installed system - without the advance consent of the user or system administrator - may be drawn outside the local network." [2]
The biggest problem to solve is the one of predictability (or lack thereof). In 2012, the collisions issue was not covered in pre-application procedures/documentation and unfortunately "sprung" on applicants late in the process. This caused applicants to face many delays and unknowns.
As for the "Workflow" slides and the process they suggest, I have major concerns:
(a) It places the enormous burden of evaluating and mitigating collision risk on the applicant a-priori, something this group discussed and rejected last year as uneven, ripe for abuse and gaming, expensive, burdensome, and fundamentally impossible;
(b) it uses honeypots rebranded as "enhanced controlled interruption" which is a practical nonstarter adding material (and likely insurmountable) risk and cost for no clear value;
(c) creates operational risk and costs by performing multiple delegations and re-delegations at the root per applied-for string with no clear value;
(d) suggests string-wise "mitigation proposals" and "remediation proposals" which are undefined, impossible to evaluate, will be enormously expensive given the liability implications, and unnecessary in nearly all cases;
(e) suggests a number of steps that simply create more data for which analysis is fundamentally subjective and open-ended and will require enormous resources in terms of both time and cost and add tremendous uncertainty, gamesmanship, and litigation risk; and
(f) kicks the can to "the Board" to make several *per-string* decisions along the way with little in the way of frameworks or guidance - inviting litigation and other (expensive, high risk) conflict that was successfully avoided in 2012 by specifically avoiding all but three string-wise Board decisions.
While many of us (myself included) find collisions intellectually interesting, we must avoid the temptation to "do more stuff" because it's interesting and instead focus on providing succinct, practical, and implementable guidance to the Board. A decade later, there is no evidence to indicate that material improvements can be made to the 2012 procedures without also introducing material new costs and risks, so we should state that and make surgical improvements. Don't break what isn't broken. Don't trade the tested and familiar - albeit imperfect - for high-risk, unknown, unproven, impractical, and in many cases unimplementable science experiments.
Jeff

[1] https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf
[2] https://itp.cdn.icann.org/en/files/name-collision/report-comments-name-collision-10jun14-en.pdf


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