[NCAP-Discuss] why enhanced controlled interruption - not legal
James Galvin
galvin at elistx.com
Mon Feb 21 20:37:50 UTC 2022
I agree Anne that that’s a logical conclusion. At least, that’s
what I believe given the data we have at hand. I’m certainly open to
being educated to some other point of view.
Jim
On 21 Feb 2022, at 15:28, Aikman-Scalese, Anne wrote:
> Thanks Jim. I note the following statement has been an underlying
> premise of our discussions for quite some time now – I believe from
> the first review of the draft Workflow document.
>
>
>
> "ECI exists because it is currently the only mechanism that has been
> proposed to obtain sufficient information to develop a mitigation or
> remediation plan. We can certainly note the additional risks that the
> ICANN Board will need to consider, that are outside the technical
> scope of our work."
>
>
>
> I support the approach taken by your email below in relation to
> identification of risks and corresponding legal issues that would have
> to be addressed. I also note that getting to the bottom of these
> issues may be very important to being able to conduct Study 3, which
> is designed to develop mitigation strategies. In other words, it
> looks to me as though appropriate mitigation strategies cannot be
> developed without ECI and that an inability to proceed to that step
> means more strings with high Impact (Volume and Diversity) will simply
> be ruled “not approved for delegation”.
>
> Anne
>
>
>
>
>
> Anne E. Aikman-Scalese
>
> Of Counsel
>
> AAikman at lewisroca.com
>
> D. 520.629.4428
>
> Lewis Roca Rothgerber Christie LLP
>
> One South Church Avenue, Suite 2000
>
> Tucson, Arizona 85701-1611
>
> lewisroca.com
>
>
>
> -----Original Message-----
> From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of James
> Galvin
> Sent: Monday, February 21, 2022 12:45 PM
> To: NCAP Discussion Group <ncap-discuss at icann.org>
> Subject: [NCAP-Discuss] why enhanced controlled interruption - not
> legal
>
>
>
> [EXTERNAL]
>
>
>
> Speaking as co-Chair:
>
>
>
> This discussion of the purpose and value of enhanced controlled
> interruption is essential. As a group we need to understand all
> points of view, make sure to defend any choice we make, and mention
> relevant counterpoints so the community understands why we made our
> choice.
>
>
>
> Toward that end I want to remind us that this is a technical group and
> we ultimately will make the best technical choice we can based on the
> data we have at hand.
>
>
>
> There are legal questions associated with the use of enhanced
> controlled interruption. There are related business, privacy, and
> liability questions. These questions have very limited scope in our
> work. It is appropriate for us to note the questions and suggest
> future study of them, but in general it is not within scope for us to
> resolve them.
>
>
>
> Let’s remind ourselves as to why enhanced controlled interruption
> (ECI) is part of our currently proposed solution.
>
>
>
> We have been asked to provide guidance on how to assess name
> collisions and consider what mitigation and remediation might be
> possible. The data we have tells us the following.
>
>
>
> 1. Root servers do not have a full picture of name collisions by
> themselves.
>
>
>
> 2. What we do know from root servers is only from DNS queries and that
> information is waning as the DNS infrastructure evolves.
>
>
>
> Those two facts alone tell us the development of a mitigation and
> remediation plan is problematic at best.
>
>
>
> ECI exists because it is currently the only mechanism that has been
> proposed to obtain sufficient information to develop a mitigation or
> remediation plan. We can certainly note the additional risks that the
> ICANN Board will need to consider, that are outside the technical
> scope of our work.
>
>
>
> Or, if another mechanism or procedure manifests in our discussions,
> then we’ll certainly consider that.
>
>
>
> I don’t want to repeat discussion we’ve already had. As we
> develop text for our final work product all of this will get discussed
> again and captured appropriately. Please do continue the discussion
> on the list as it will inform our final work product.
>
>
>
> Thanks,
>
>
>
> Jim
>
> _______________________________________________
>
> 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/20220221/5a49fbdb/attachment.html>
More information about the NCAP-Discuss
mailing list