[NCAP-Discuss] Sub Pro Final Report Recommendations
Aikman-Scalese, Anne
AAikman at lewisroca.com
Wed May 11 21:31:46 UTC 2022
From the Final Report text in relation to Implementation Guidance:
Implementation Guidance: The Working Group strongly recommends the stated action, with a
strong presumption that it will be implemented, but recognizes that there may exist valid
reasons in particular circumstances to not take the recommended action exactly as described.
However, the party to whom the action is directed must make all efforts to achieve the
purpose behind the recommended action (as expressed in the rationale and the
recommendation to which the implementation guidance is linked, if applicable) even if done
through a different course. In all cases, the full implications must be understood and carefully
weighed before choosing a different course. Implementation guidance commonly refers to
how a recommendation should be implemented. Implementation guidance typically uses the
term “should” indicating that the Working Group expects the action to take place, noting the
caveats above.
Anne E. Aikman-Scalese
Of Counsel
AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>
D. 520.629.4428
[cid:image003.png at 01D86543.D6544210]
From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Rubens Kuhl via NCAP-Discuss
Sent: Wednesday, May 11, 2022 2:16 PM
To: NCAP Discussion Group <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Sub Pro Final Report Recommendations
Implementation guidance, as evidenced by the frequent use of "should" and "to the extent possible", is something that is nice to have, but not required, even if the Board approves it exactly as written. So if NCAP wants to take that into consideration, the proper weight is the SHOULD as in RFC 2119/BCP 14.
Rubens
On 11 May 2022, at 17:04, Aikman-Scalese, Anne <AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>> wrote:
Jeff,
The Sub Pro Working Group had concerns that NCAP work might not be done before the next round was launched. This was before the Working Group found out there would be an ODP and before the Board authorized NCAP Study 2. We are now well past these points.
With regard to the nature of the “mechanism to evaluate the risk of name collisions” that is required by 29.1, the Implementation Guidance from the Sub Pro Final Report is helpful:
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
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.
Anne
Anne E. Aikman-Scalese
Of Counsel
<image004.png>
AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>
D. 520.629.4428
<image007.png>
From: Jeff Schmidt <jschmidt at jasadvisors.com<mailto:jschmidt at jasadvisors.com>>
Sent: Monday, May 9, 2022 11:48 AM
To: Aikman-Scalese, Anne <AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>>; NCAP Discussion Group <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
Subject: RE: The threshold of harm issue
[EXTERNAL]
________________________________
Recommendation 29.1: ICANN must 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.
Not sure where there is any room for debate. SubPro is crystal clear: “use the New gTLD Collision Occurrence Management framework unless and until the ICANN Board adopts a new mitigation framework” – the referenced 2012 round framework includes “the mechanism to evaluate the risk of name collisions” appearing in 29.1.
As for the call last week (which I was on), it is wildly optimistic to characterize that as “progress.” I will describe my thoughts in a subsequent email to the group.
Jeff
From: Aikman-Scalese, Anne <AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>>
Sent: Monday, May 9, 2022 1:37 PM
To: Jeff Schmidt <jschmidt at jasadvisors.com<mailto:jschmidt at jasadvisors.com>>; NCAP Discussion Group <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
Subject: RE: The threshold of harm issue
Respectfully, Jeff, I don’t think you are acknowledging the impact of Sub Pro Recommendation 29.1. As to the progress being made, and having just listened to the Zoom, I think last Wednesday’s meeting proves progress is in fact being made.
Respectfully, something else that your approach does not take into account is the fact that the SSAC has to answer the Board’s question and the NCAP process is the mechanism chosen by the SSAC to accomplish this.
Anne
Anne E. Aikman-Scalese
Of Counsel
<image005.jpg>
AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>
D. 520.629.4428
<image007.png>
From: Jeff Schmidt <jschmidt at jasadvisors.com<mailto:jschmidt at jasadvisors.com>>
Sent: Monday, May 9, 2022 11:33 AM
To: Aikman-Scalese, Anne <AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>>; NCAP Discussion Group <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
Subject: RE: The threshold of harm issue
[EXTERNAL]
________________________________
Anne, again, with respect, that makes no sense.
While I was not involved with SubPro, they clearly and sensibly took the position that unless NCAP can come-up with something better, ICANN should do what it did in the 2012 round vis-à-vis collisions.
In four years of NCAP and a lot of time and money spent, it is inarguable that we have not come-up with anything better. We should have the courage and intellectual honesty to say that and move on.
Jeff
From: Aikman-Scalese, Anne <AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>>
Sent: Friday, April 29, 2022 6:17 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 – 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
<image005.jpg>
AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>
D. 520.629.4428
<image007.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
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
<image005.jpg>
AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>
D. 520.629.4428
<image011.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.
________________________________
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<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/20220511/c61adc1a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2031 bytes
Desc: image003.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220511/c61adc1a/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 209 bytes
Desc: image004.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220511/c61adc1a/image004-0001.png>
More information about the NCAP-Discuss
mailing list