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

Thu Feb 17 19:38:59 UTC 2022

Anne,

Compromise and commitment to forward movement goes both ways. What Jeff Schmidt reminded us can be summarized by two things:
- There is a new analysis process being suggested, but there is no rationale on which goals this new process is aiming to achieve, and why those are worthy pursuing.
- There is an old mechanism being yet again reintroduced, while the underlying conditions for its use only became worse since 2012.

Wanting to change just because is not good enough. Change needs to be meaningful to be called progress.

Rubens

> On 17 Feb 2022, at 14:30, Aikman-Scalese, Anne <AAikman at lewisroca.com> wrote:
> 
> Sorry Jeff.  I got my “Jeffs” mixed up.  I guess there is no reason Jeff Schmidt would be aware of the Sub Pro Policy outcomes.
> 
> At any rate, I keep trying to get references to the Sub Pro Final Report incorporated somehow into the work of the NCAP because, let’s face it – when the Board has conflicting advice from two different sources, in recent years they tend to send it back to the Community for further policy work or else it comes to a standstill because they have conflicting advice.  That “bottleneck” is a killer for the ICANN DNS and the MSM system.   Now decentralized domains are flourishing.  ICANN is starting to look like a gigantic slow-moving dinosaur.
> 
> If different arms/elements of the Community don’t start coordinating their efforts toward RESULTS, we will rot on the vine.  The Board routinely  takes the position that it does not “make policy” but if the result of that is “no forward movement”,   then the ICANN Mission is not being accomplished.  I think the Board is looking for us to resolve issues before they take action.  Sub Pro said that if NCAP process develops a new Name Collision Framework that is recommended by the SSAC and then adopted by the Board, then it should apply to the next round.  That Recommendation in the Sub Pro Final Report is important because it eliminates a conflict.  Some folks may want to stop this NCAP process in its tracks because they believe 90-day controlled interruption should apply.  We do have to take into account what is happening at the Board level.  There is also a responsibility for members of this NCAP Discussion Group to proceed in a manner that seeks compromise, not just insist on a position in favor of 90-day controlled interruption when we are all participating in good faith in the NCAP process.
> 
> At any rate, Casey is looking at some additional data over the past few years which may be enlightening.
> 
> Anne
> 
> Anne E. Aikman-Scalese
> Of Counsel
> <image003.png>
> AAikman at lewisroca.com <mailto:AAikman at lewisroca.com>
> D. 520.629.4428
> <image006.png>
> 
> From: Jeff Neuman <jeff at jjnsolutions.com <mailto:jeff at jjnsolutions.com>>
> Sent: Thursday, February 17, 2022 12:28 AM
> To: Aikman-Scalese, Anne <AAikman at lewisroca.com <mailto:AAikman at lewisroca.com>>; rubensk at nic.br <mailto:rubensk at nic.br>
> Cc: ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>
> Subject: RE: [NCAP-Discuss] Reflecting on the 'big picture' and making our outputs helpful to the Community
> 
> [EXTERNAL]
> Anne,
> 
> I am not sure why you addressed this to me as I have not weighed in on this yet.  I believe you meant Jeff Schmidt who sent this e-mail.  I do, however, support the statements that Jeff S. has made.
> 
> Sincerely,
> 
> Jeff Neuman
> 
> <image005.png>
> Jeffrey J. Neuman
> Founder & CEO
> JJN Solutions, LLC
> p: +1.202.549.5079
> E: jeff at jjnsolutions.com <mailto:jeff at jjnsolutions.com>
> http://jjnsolutions.com <http://jjnsolutions.com/>
> 
> 
> From: Aikman-Scalese, Anne <AAikman at lewisroca.com <mailto:AAikman at lewisroca.com>>
> Sent: Wednesday, February 16, 2022 1:48 PM
> To: rubensk at nic.br <mailto:rubensk at nic.br>; Jeff Neuman <jeff at jjnsolutions.com <mailto:jeff at jjnsolutions.com>>
> Cc: ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>
> Subject: RE: [NCAP-Discuss] Reflecting on the 'big picture' and making our outputs helpful to the Community
> 
> 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
> <image003.png>
> AAikman at lewisroca.com <mailto:AAikman at lewisroca.com>
> D. 520.629.4428
> <image006.png>
> 
> From: NCAP-Discuss <ncap-discuss-bounces at icann.org <mailto: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 <mailto: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 <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 <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 <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
> 
> 
> 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/20220217/ffc2bbca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220217/ffc2bbca/signature-0001.asc>