[NCAP-Discuss] why enhanced controlled interruption - not legal

[James Galvin]

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>