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

Wed Feb 16 18:48:04 UTC 2022

Jeff and Rubens,
Having participated actively in Sub Pro, I am not surprised by the approach you have both taken in your comments, though they do seem to be a bit “late-breaking” in terms of the process the DG has been following. The Workflow document has been around for a long time.

I’ll also note that Sub Pro Recommendations in the Final Report (adopted by the GNSO Council and sent to the ICANN Board) state that

(1)    ICANN should develop a DO NOT APPLY list for names that have too great a risk of potential harm.  (The potential harms were identified in NCAP Study 1).

(2)    Any New Name Collision Framework coming out of the NCAP process and recommended to the Board by SSAC (which is adopted by the Board in time for the next round) should govern.  Considering the projected time frame for the ODP, there should be ample time for this  process to “dovetail” the development of an AGB.  And the ODP notes that this issue of a possible new Name Collision Framework has to be resolved.

Reports of name collision issues to ICANN based on the 2012 round and the “lack of litigation” in this realm is not a reliable measure for answering the issues raised by NCAP Study 1 or the Board’s specific questions to the SSAC on this topic.  Those Board questions have been guiding the work of the DG for months and there is also recognition that the DNS is not static.

I don’t think NCAP DG is a forum designed to revisit the policy work already done in Sub Pro and the Recommendations that came out of that process.  And I don’t think the NCAP DG can ignore the specific questions posed by the Board and the results of Study 1 by simply saying – “well, it seems to us it all went just fine in the 2012 round.”
Anne

Anne E. Aikman-Scalese

Of Counsel

AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>

D. 520.629.4428

[cid:image003.png at 01D82329.4578B700]

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Rubens Kuhl via NCAP-Discuss
Sent: Wednesday, February 16, 2022 11:18 AM
To: ncap-discuss at icann.org
Subject: Re: [NCAP-Discuss] Reflecting on the 'big picture' and making our outputs helpful to the Community

Besides agreeing wholeheartedly with Jeff, I will just add that this rehashing of old ideas is a good part of the paralysis disease plaguing ICANN (Org + Community) at this point.
But name collisions has been used in the past to stall this same root zone expansion program, so this is not a new script, just a new episode of the series.

Rubens

On 16 Feb 2022, at 13:25, Jeff Schmidt via NCAP-Discuss <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>> wrote:

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

_______________________________________________
NCAP-Discuss mailing list
NCAP-Discuss at icann.org<mailto: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.

________________________________

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/20220216/738445cc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2031 bytes
Desc: image003.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220216/738445cc/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 212 bytes
Desc: image002.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220216/738445cc/image002-0001.png>