[NCAP-Discuss] Enhanced Controlled Interruption and Predictability

Thu Feb 24 15:46:24 UTC 2022

The Board's overarching goal should be to prevent or minimize consumer harm
in approving new delegations.

I don't think it is relevant whether potential collisions are accidental or
deliberate.  In either case, whether the potential collisions become actual
collisions is entirely under ICANN's control and the Board will still want
to be able to understand the consumer harm that would be caused with a new
delegation.

This simply may not align with giving predictability to new gtld
applicants.

Since assessing consumer harm is beyond the remit of the NCAP's current
study, I suspect that they will return to SSAC and ask for another study.

Tom

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#m_-8778590085366565544_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Feb 24, 2022 at 10:01 AM Jeff Neuman <jeff at jjnsolutions.com> wrote:

> 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.
>
>
>
> Jeffrey J. Neuman
>
> Founder & CEO
>
> JJN Solutions, LLC
>
> p: +1.202.549.5079
>
> E: jeff at jjnsolutions.com
>
> http://jjnsolutions.com
>
>
>
>
>
> *From:* Aikman-Scalese, Anne <AAikman at lewisroca.com>
> *Sent:* Wednesday, February 23, 2022 3:25 PM
> *To:* Jeff Neuman <jeff at jjnsolutions.com>; 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
>
> D. 520.629.4428
>
>
>
> *From:* NCAP-Discuss <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
> *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.
>
>
>
> Jeffrey J. Neuman
>
> Founder & CEO
>
> JJN Solutions, LLC
>
> p: +1.202.549.5079
>
> E: 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.
> _______________________________________________
> NCAP-Discuss mailing list
> 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.

-- 
Thomas Barrett
President
EnCirca, Inc
+1.781.942.9975 (office)
400 W. Cummings Park, Suite 1725
Woburn, MA 01801 USA

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#m_-8778590085366565544_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/6bf8b611/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 67520 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/6bf8b611/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 212 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/6bf8b611/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 2031 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/6bf8b611/image004-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 14520 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220224/6bf8b611/image005-0001.png>