[NCAP-Discuss] The threshold of harm issue

Sat Apr 30 19:46:48 UTC 2022

Anne,

I actively participated in SubPro, including in the work track that discussed name collisions, and your reading of the harm topic doesn't match either the discussions or the final report.

The harm aspect was first discussed in relation to the 2012 round, since one of the few charter questions about collisions in that round was about harm threshold and harm readiness. In the end, recommendation 29.2 reflected the group consensus, which kept the harm level and readiness as they were for already delegated TLDs and future TLDs:
"
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"

29.1 recommendation that you mentioned only talks about measuring risk. While risk is the probability of a harm occurring, it doesn't define harm. What defines harm in the report is affirmation of the 2012 management framework, which then has definitions of harm.

So, if you are suggesting NCAP to follow the SubPro report, this include keeping the harm definition that Jeff S mentioned in this thread.

Rubens

> On 29 Apr 2022, at 20:16, Aikman-Scalese, Anne <AAikman at lewisroca.com> wrote:
> 
> Jeff – at this point all I can say is that maybe you should have participated more actively in Sub Pro.  The policy recommendations from the PDP Consensus are before the Board.
> Anne
> 
> Anne E. Aikman-Scalese
> Of Counsel
> <image002.png>
> AAikman at lewisroca.com <mailto:AAikman at lewisroca.com>
> D. 520.629.4428
> <image005.png>
> 
> From: Jeff Schmidt <jschmidt at jasadvisors.com <mailto:jschmidt at jasadvisors.com>>
> Sent: Friday, April 29, 2022 2:59 PM
> To: Aikman-Scalese, Anne <AAikman at lewisroca.com <mailto:AAikman at lewisroca.com>>
> Cc: NCAP Discussion Group <ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>>
> Subject: Re: The threshold of harm issue
> 
> [EXTERNAL]
> Anne – respectfully, you didn’t address my concern or any of my 4 questions. You dodged the issue with the tired “yes but bad things might happen!” argument that gets us nowhere.
> 
> What is the acceptable level of “harm?” If one computer is down for one hour, is that too much? Defining the level of acceptable harm is a necessary pre-requisite to everything you suggest needs to be done. You state: “…get a system in place that avoids applications being made for strings that actually pose too much risk from a name collision standpoint…” I’m asking us to carefully define the “too much risk” part. We have not, and it sounds like we have implicitly defined it as “zero risk is acceptable.”
> 
> It’s a hard slippery slope problem. No one wants to see anyone harmed for any period of time. But the Internet is a messy place and any innovation -- really any change -- causes non-zero risk. If we are truly adopting a zero-acceptable-risk posture, then the only intellectually-honest position for NCAP is to (1) recommend against the addition of new TLDs, and (2) recommend that the transfer of any existing Registration in all existing TLDs be prohibited. Lest we forget: the most dangerous collisions -- bar none -- happen in .com – simply as a product of its size, popularity, and dynamism.
> 
> Anne, please read our report starting at page 11 where we address the “harm” issue:
> 
> https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf <https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf>
> 
> Jeff
> 
> 
> From: Aikman-Scalese, Anne <AAikman at lewisroca.com <mailto:AAikman at lewisroca.com>>
> Date: Friday, April 29, 2022 at 4:26 PM
> To: Jeff Schmidt <jschmidt at jasadvisors.com <mailto:jschmidt at jasadvisors.com>>
> Cc: NCAP Discussion Group <ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>>
> Subject: RE: The threshold of harm issue
> 
> Jeff,
> As you know, I heartily disagree with your conclusion that if there were harms occurring to consumers in the name collision arena, we would know about it.  There is no way consumers are going to search for ICANN reporting systems.  They mostly have no idea what ICANN is and what it does.  If the consumer is the subject of a Man in The Middle Attack (which you agreed in chat in our Wednesday meeting can happen anytime)  the consumer is just going to say “I’m the victim of fraud and I don’t know where to go to get that fixed.”
> 
> There is no evidence for your conclusion that this type of harm is a “hiccup”.  It affects the Security and  Stability of the Internet and Consumer Trust and Confidence in the DNS.  Reports apparently appeared on blogs and the results of Casey’s report in relation to system harm should not be ignored.
> 
> The Sub Pro Final Report Recommendation 29.1 clearly states that the Board MUST have a system in place for assessing name collision risk and that is exactly what has been happening here for months – trying to develop a system that meets that Sub Pro Final Recommendation.    It would be great if folks could move forward constructively to get a system in place that avoids applications being made for strings that actually pose too much risk from a name collision standpoint the so-called DO NOT APPLY list referenced in the Sub Pro Final Report.
> 
> As I pointed out on the Wednesday call, it would also be great if the system being developed were to allow for individual applicants to submit mitigation/remediation plans where volume and diversity of name collisions creates a fairly high level of risk – all in accordance with the Sub Pro Final Report Recommendations.    The Workflow is evolving in that direction and that is positive.
> 
> Anne
> 
> 
> Anne E. Aikman-Scalese
> Of Counsel
> <image003.png>
> AAikman at lewisroca.com <mailto:AAikman at lewisroca.com>
> D. 520.629.4428
> <image008.png>
> 
> From: NCAP-Discuss <ncap-discuss-bounces at icann.org <mailto:ncap-discuss-bounces at icann.org>> On Behalf Of Jeff Schmidt via NCAP-Discuss
> Sent: Friday, April 29, 2022 1:59 PM
> To: ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>
> Subject: [NCAP-Discuss] The threshold of harm issue
> 
> [EXTERNAL]
> We must address the threshold of harm issue. Our collective failure to address this head-on results in the “but bad things might happen!” logic that is currently, and unhelpfully, driving this group.
> 
> During the call this week, I again brought-up the importance of calling-out what *specific* problems from the 2012 round we are trying to remedy, in agreement with the public comment we were reviewing. NCAP has never done this. As a response to this during the call, someone pasted in the chat one of the horror-stories self-reported to ICANN’s collisions reporting system. It was – roughly - along the lines of X machines were unavailable in Y offices globally, for Z period of time to remediate. The implication was that this was unacceptable and is a problem that needs to be solved in the next round.
> 
> Question 1: Is it?
> 
> Question 2: What about X-1 machines in Y-1 global offices? What if Z was a day, a week, or a month?
> 
> Question 3: What if it was a hairdresser? What if it was an electric utility? What if it was the propaganda arm of a national government we disagree with?
> 
> Question 4: Does there arise a duty to verify self-reported harms given that it could cause a scenario that will negatively impact someone else (i.e. will a self-reported harm deny an applicant the string they want or cause an increase in the applicant’s costs to obtain said string (because of “mitigation strategies,” etc.) given some unverified, self-reported harm?
> 
> I realize most folks on this list have not read our reports. I would encourage (beg?) each of you to do so. We discuss this topic deliberately and the resulting impossible slippery slope problem. The reason for the high threshold (“impact to human life”) is very deliberate, well-reasoned, and as appropriate now as it was years ago.
> 
> If we consider basically any Internet-age hiccup (spam, malware, MITM, transient outages, etc) as an unacceptable harm if they’re caused by collisions, we need to say that and define a threshold. Else, we’re kicking the can for the Board to make these determinations which is not a winning strategy.
> 
> Jeff
> 
> 
> 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.
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220430/ba469b41/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page134image43267200.png
Type: image/png
Size: 245 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220430/ba469b41/page134image43267200-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page134image43265280.png
Type: image/png
Size: 240 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220430/ba469b41/page134image43265280-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page134image43265088.png
Type: image/png
Size: 248 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220430/ba469b41/page134image43265088-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page134image43266048.png
Type: image/png
Size: 243 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220430/ba469b41/page134image43266048-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220430/ba469b41/signature-0001.asc>