[NCAP-Discuss] Enhanced Controlled Interruption and Predictability

Thu Feb 24 17:03:20 UTC 2022

Hi Jeff.  You make it sound as though the Sub Pro Working group was somehow going to recommend or require additional policy work to arrive at a new Name Collision Framework.  This is not the case.  The Recommendation and Implementation Guidance appears below.  In this regard, I know that you know that the term "MUST" is a defined term in the Final Report.  I consider the work being done in NCAP to be fulfilling Recommendation 29.1 and "use the old system from 2012" is certainly not an answer to this Final Report Recommendation 29.1.  (This will only slow the process if we cannot achieve constructive participation to fulfill 29.1  because the Board will say - as part of ODP - "go back and work it out".)
Anne

Topic 29: Name Collisions
a. Recommendations and/or implementation guidelines
Recommendation 4 from the 2007 policy is affirmed under Topic 26: Security and
Stability. Recommendation 4 is also relevant to this topic.

Recommendation 29.1: ICANN must (emphasis mine) have ready prior to the opening of the Application Submission Period a mechanism to evaluate the risk of name collisions in the New gTLD evaluation process as well as during the transition to delegation phase.

Affirmation 29.2: The Working Group affirms continued use of the New gTLD Collision
Occurrence Management framework unless and until the ICANN Board adopts a new
mitigation framework. This includes not changing the controlled interruption duration
and the required readiness for human-life threatening conditions for currently delegated
gTLDs and future new gTLDs.186
Implementation Guidance 29.3: To the extent possible, ICANN should seek to
identify high-risk strings in advance of opening the Application Submission
Period, which should constitute a "Do Not Apply" list. ICANN should also seek
186 "Registry Operators will implement a period of, at least, 90 days of continuous controlled interruption.
ICANN will monitor and time the implementation of the measure, primarily using the zone files that are
transferred to ICANN from new gTLD registries once they are delegated (per Specification 4 off the new
gTLD Registry Agreement).", 3. Controlled Interruption, and 7. Emergency Response, pages 2 and 4, in the
New gTLD Collision Occurrence Management framework. See:
https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf.
New gTLD Subsequent Procedures Final Report Date: 20 January 2021
Page 135 of 400
to identify aggravated risk strings in advance of the next application window
opening and whether it would require a specific name collision mitigation
framework.
Implementation Guidance 29.4: To the extent possible, all applied-for strings
should be subject to a DNS Stability evaluation to determine whether they
represent a name collision risk.
Implementation Guidance 29.5: The ICANN community should develop name
collision risk criteria and a test to provide information to an applicant for any
given string after the application window closes so that the applicant can
determine if they should move forward with evaluation.
Implementation Guidance 29.6: If controlled interruption (CI) for a specific label
(usually a 2nd-level domain) is found to cause disruption, ICANN may decide to
allow CI to be disabled for that label while the disruption is fixed, provided that
the minimum CI period is still applied to that label.

Anne E. Aikman-Scalese

Of Counsel

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

D. 520.629.4428

[cid:image007.png at 01D82965.BABACE30]

From: Jeff Neuman <jeff at jjnsolutions.com>
Sent: Thursday, February 24, 2022 8:01 AM
To: Aikman-Scalese, Anne <AAikman at lewisroca.com>; ncap-discuss at icann.org
Subject: RE: Enhanced Controlled Interruption and Predictability

[EXTERNAL]
________________________________
Anne,

That is a misstatement of SubPro Recommendations:

Here is what it says:  "The Working Group affirms continued use of the New gTLD Collision Occurrence Management framework unless and until the ICANN Board adopts a new mitigation framework."  It references the NCAP in the rationale of course as working on the issue, but it never just delegated all policy to the NCAP or SSAC to decide.  That is no where in the recommendations or rationale.  The SubPro Recommendation never states that the GNSO waives all of its policy development rights in favor of the NCAP Study Group.  In fact, it is quite the opposite by stating "The Working Group agreed that it is up to the ICANN community and ICANN Board of Directors to determine any dependencies between the NCAP and the next round of new gTLD applications" See https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-20jan21-en.pdf, starting on Page 134 (Topic 29).

So, putting the recommendations of SubPro aside for the moment, I am not saying that the SSAC should develop the mitigation plans, but rather that this group, the SSAC, and the community need to make the process incredibly predictable and provide guidelines to applicants (and instructions) on how to create an acceptable mitigation plan.  ICANN can ask an applicant to submit a mitigation plan addressing the issues found, but who the heck is going to know how to come up with an acceptable mitigation plan.  There are very few experts globally that even know what name collision means, much less know what the implications of collision are.  I would venture to say that there are even few people that would know how to draft a Name Collision mitigation plan, especially because we cant even quantify the harm that needs to be mitigated.  In short, it is an impossible task that is fraught with unknown subjectivity depending on the beliefs, expertise and biases of the evaluator.  That is a process to me that is doomed to fail, cause expensive litigation, and in exchange for what?  ---- Trying to solve a situation which we really will never know is a problem or not.

Yes, we have data that there are collisions going on.  Great.  We have no idea if it is causing actual harm, no idea if those causing the collisions actually know or care about the collisions, have no idea whether the collisions are intentional or accidental, etc.  Yet, by requiring "mitigation", we are assuming (a) the collisions are unintentional, (b) they are causing harm, (c) the benefit of implementing controlled interruption is greater than the risks associated with the name collision, etc......

Having lots of data with no understanding of what it means is not a great way to set policies that can have significant repercussions and costs.

[cid:image003.png at 01D82965.BCA38B60]

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: Aikman-Scalese, Anne <AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>>
Sent: Wednesday, February 23, 2022 3:25 PM
To: Jeff Neuman <jeff at jjnsolutions.com<mailto:jeff at jjnsolutions.com>>; ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>
Subject: RE: Enhanced Controlled Interruption and Predictability

Jeff - the policy was already developed in Sub Pro.  As far as I know, it states very clearly that if NCAP develops a new Name Collision Framework that is recommended to the Board and the Board adopts it, that new Name Collision Framework will apply.  It's one of the formal Recommendations in the Sub Pro Final Report and this contingency is noted in the ODP for the next round.

What am I missing as to your comment re policy development?
Anne

Anne E. Aikman-Scalese

Of Counsel

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

D. 520.629.4428

[cid:image007.png at 01D82965.BABACE30]

From: NCAP-Discuss <ncap-discuss-bounces at icann.org<mailto:ncap-discuss-bounces at icann.org>> On Behalf Of Jeff Neuman
Sent: Tuesday, February 22, 2022 11:58 AM
To: ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>
Subject: [NCAP-Discuss] Enhanced Controlled Interruption and Predictability

[EXTERNAL]
________________________________
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:image005.png at 01D82965.BCA38B60]

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

________________________________

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/20220224/66e16522/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 2031 bytes
Desc: image007.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/66e16522/image007-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 217 bytes
Desc: image002.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/66e16522/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 14526 bytes
Desc: image003.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/66e16522/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 212 bytes
Desc: image004.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/66e16522/image004-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 14638 bytes
Desc: image005.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/66e16522/image005-0001.png>