[Gnso-newgtld-wg] ICANN's Ability to Act (Without Using Predictability Model)
AAikman at lrrc.com
Fri Oct 30 23:37:54 UTC 2020
I don't actually see any way for us as a WG to constrain the Board when it determines it needs to act based on the exercise of fiduciary duty by each individual member. We did not choose a membership organization in the IANA transition. We chose a non-profit corporation. So the Board's accountability is to the corporation, not to the community.
I think we would just have to say that "The foregoing notwithstanding, it is understood that the ICANN Board may need to exercise its fiduciary duty to act in emergency situations to address security and stability concerns, as well as to preserve the proper functioning of the Internet's systems. In such cases, the Board will notify all Empowered Community representatives in writing within 24 hours of taking such action."
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> On Behalf Of Jeff Neuman
Sent: Friday, October 30, 2020 4:09 PM
To: gnso-newgtld-wg at icann.org
Subject: [Gnso-newgtld-wg] ICANN's Ability to Act (Without Using Predictability Model)
On the last cast, towards the end of the call, when dealing with Systems (Topic 14)<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1YQsepwk-Q/edit#gid=123470843>, ICANN Org made the following Comment:
a) Our Recommendation from Draft Final Report: ""in service of transparency, once the systems are in use, ICANN should communicate any system changes that may impact applicants or the application process. Processes described under Topic 2: Predictability should be followed."
b) ICANN Org Comment: "ICANN org would like to note that for issues related to security and stability, as well as the proper functioning of systems, ICANN org cannot be constrained to the processes outlined under Topic 2. ICANN org will need to respond rapidly to any issue that may fall under these categories."
1. Under Predictability (Topic 2)<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpRyaAE1ctI/edit#gid=1688811020>, another version of this came up and has been discussed in the last email exchange to which Donna, Anne and I responded. In that discussion, ICANN said that it needed "the right to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities."
a) Donna, Anne and I agreed that in true emergencies, ICANN does need to be able to act in emergency situations. We also agreed that it was critical that ICANN be transparent when it acts, and that Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately.
b) I had suggested narrowing the scope of what constitutes emergencies, but Donna and Anne did not necessarily think that would be possible.
1. Here, under Systems<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1YQsepwk-Q/edit#gid=123470843>, ICANN Org has broadened this to not just include "emergency situations", but also any issues "related to security and stability as well as the proper functioning of systems."
a) This is a much more expansive list of situations where ICANN would not have to use the Predictability Model.
b) In line with the above, it certainly makes sense that any issues that created an emergency situation with respect to the systems, should allow ICANN to act quickly without the use of the Predictability Model. I could see this including things like responding to a data breach or other imminent security vulnerability. We could also see responding to other forms of Cyberattack, DDoS, etc.
Question: However, is the Working Group concerned that the language "related to" and "Proper functioning of systems' is too wide an opening to allow ICANN to always make changes without using the Predictability Model / SPIRT? For example, one could argue that the creation of Digital Archery was an act related to security and stability. Changing the Pre Delegation Testing Requirements could easily be related to security and stability, etc.
Jeff Neuman Recommendation: We should be consistent in setting out when ICANN Org / Board should be excused from using the Predictability Model to act. Certainly Emergency Situations should be covered with the Transparency requirements discussed in #1 above. Perhaps stating something like:
"With respect to its operation and administration of the systems, ICANN must retain the ability to act in emergency situations, including those where immediate action is necessary to remedy any service interruption, interference, service obstruction or other imminent threat to the systems; provided that ICANN provides notice to all impacted users of the affected system(s) as soon as reasonably practicable after such action has been taken along, and if such action involves any downtime to the system(s), it shall provide updates to impacted users as to when normal service can be restored."
[cid:image002.png at 01D6AEDA.D88CAD90]
Jeffrey J. Neuman
Founder & CEO
JJN Solutions, LLC
E: jeff at jjnsolutions.com<mailto:jeff at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9593 bytes
More information about the Gnso-newgtld-wg