[NCAP-Discuss] Enhanced Controlled Interruption and Predictability

Wed Feb 23 20:18:38 UTC 2022

Hi Jeff,
Hopefully I have the right Jeff this time!  I am a little surprised by your suggestion that the NCAP DG and the SSAC need to develop mitigation plan solutions for Applicants.   The reason I am surprised is that if recollection serves, there was significant discussion in Sub Pro about enabling and encouraging Applicants to submit individual mitigation plans that the Applicant would propose to ICANN.  (This would presumably follow CI or second step ECI, whichever one is necessary based on the Impact.)

Wouldn’t you want Applicants to be able to propose their own mitigation plans for approval by ICANN?  (I was actually thinking this was “baked in” to the Sub Pro Final Report.  Or am I dreaming?)
Anne

Anne E. Aikman-Scalese

Of Counsel

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

D. 520.629.4428

[cid:image004.png at 01D828B7.DBD909F0]

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Jeff Neuman
Sent: Tuesday, February 22, 2022 1:20 PM
To: James Galvin <galvin at elistx.com>
Cc: ncap-discuss at icann.org
Subject: Re: [NCAP-Discuss] Enhanced Controlled Interruption and Predictability

[EXTERNAL]
________________________________
James,

The approach you have set forth sounds good in theory, but in practice is fraught with uncertainty and will invariably lead to incredible amounts of delay for a situation where even if there is data of collisions, there may be no evidence of truly adverse consequences from the collisions.

And to top if off, the concept of mitigating collisions with one or more organizations that may not know (or care) about the collisions is a nearly impossible task.

The reason I am not in favor of this new approach is that it shifts all of the burden to the those wanting to see the TLD delegated as opposed to the those that either (a) misconfigured their systems, or worse (b) intentionally configured their systems in such a way to take advantage of the fact that ICANN has not delegated that particular string.  And this is where it all breaks down.

It would be one thing if we could show that entities are (or will be) truly hurt by these collisions.  But to assume that they will be hurt and then to put a burden on those seeking delegation when it is just as possible that the collisions are being caused by intentional activities to me seems wrong.

Therefore, when you state that the applicant needs to have a mitigation plan, what does that mean?  What guidance do we have for those plans?  How is an applicant supposed to know what to do.  And how can an applicant mitigate a situation where the colliding entity does not know (or potentially does not care) that there are collisions.

If we require a mitigation plan, it needs to be one that is predictable and not outcome based.  In other words, the Applicant should only be required to do what is reasonable and if the colliding entity(ies) do not know about it, or care about it, then the applicant should not be held responsible at all.

Finally, any technical solution requires policy folks to look at the technical solution to see if it is an acceptable policy outcome.  In other words, the policy folks should be able to override any technical solution if it is determined that there are other more important policy considerations than the ones we are attempting to mitigate.

ICANN too frequently takes “advice” from the SSAC as being advice from up above and therefore feels compelled to adopt it for fear of risking the security and stability of the Internet.  However, I do not see our proposed solution as solving something that threatens the security and stability of the Internet, but rather as solving a situation that perhaps threatens an individual organization that is causing the potential collisions.   I am not saying that it is not important work, but perhaps the policies of predictability and the other new gTLD policies could override the speculative potential harm by any of these collisions.

Just some food for thought.

[cid:image007.png at 01D828B7.DBEF02F0]

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

From: James Galvin <galvin at elistx.com<mailto:galvin at elistx.com>>
Sent: Tuesday, February 22, 2022 2:46 PM
To: 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] Enhanced Controlled Interruption and Predictability

Excellent questions, Jeff. Speaking personally, I think your questions fit in that space between purely technical and purely legal. policy, and business.

I would say we are obligated to inform the Board with our best advice on how to interpret the data showing the existence of name collisions and then how to review mitigation and remediation plans. So we have to say something about your questions, beyond just listing them.

I don’t think we’re going to be able to propose a solution that is 100% predictable though. I’d be delighted to be educated differently.

Other folks should certainly offer their own ideas for how to answer your questions. Here are some ideas from me for folks to consider.

1. ECI is conducted, data is collected (details still to be defined), and data is made available to Applicant and Technical Review Team.

2. Applicant develops either or both a mitigation plan or remediation plan.

3. Technical Review Team develops summary of what the collected data means, the Applicant plan(s), and a technical indication of the extent to which the plan(s) address the aforementioned issues. Think of this as technical due diligence in much the same way that Staff effectuate due diligence on the rest of the application.

4. The Board reviews the original application, its due diligence report from ICANN staff, the plan(s) from the Applicant, and the independent review conducted by the Technical Review Team to decide whether or not to delegate the TLD to the Applicant.

What are the benefits of our approach?

Data will be collected about the existence of name collisions for each proposed application, each Applicant will have the opportunity to address what the data shows, and then the Board will be able to make a decision about the Application. These three steps had an extremely limited presence in the 2012 round. In particular, although most TLDs were granted, we have three that are still officially “deferred”, since we didn’t have a means to properly evaluate them.

We are developing a proposal to do just that.

Alternate points of view and proposals are most welcome!

Jim

On 22 Feb 2022, at 13:58, Jeff Neuman wrote:
All,

Purposefully, I am going to ignore all of the legal, policy and business reasons to do (or not do) Enhanced Controlled Interruption.  The question I have is whether ECI violates the GNSO Unanimous Consensus Policy that all processed and procedures surrounding the introduction of new gTLDs be predictable.

Lets suppose we do Enhanced Controlled Interruption and there is a whole lot of data collected by some Honeypot operator.  Then what?  The Honeypot Operator (HPO) attempts to contact those that have misconfigured servers or whatever.  But what then?  Who makes the decision to allow (or not allow) the delegation of the TLD to the Registry Operator to continue so that it can launch the TLD?  What criteria is used by the decision maker to either allow or not allow the next steps to go forward?  Does this just create more uncertainty by another decision maker inserted into the process to decide if and when the next steps of the launch can proceed?   How does that enhance predictability in the process?

I understand that this is a “technical group”, but the Board needs to be told explicitly that we are only recommending what we as the technical group think should happen, but that the policy needs to be developed to determine whether the benefits of this new technical approach are outweighed by the other policy aspects of implementing the next rounds of new TLDs.

I hope that makes sense.

[cid:image001.png at 01D827F4.364CB590]

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

_______________________________________________
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/20220223/19d59171/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 2031 bytes
Desc: image004.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220223/19d59171/image004-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 212 bytes
Desc: image001.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220223/19d59171/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 14541 bytes
Desc: image007.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220223/19d59171/image007-0001.png>