ICANN's Ability to Act (Without Using Predictability Model)
All. On the last cast, towards the end of the call, when dealing with Systems (Topic 14)<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1YQ...>, ICANN Org made the following Comment: 1. 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." 1. 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." Discussion - 1. Under Predictability (Topic 2)<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpRy...>, 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." 1. 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. 2. 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/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1YQ...>, 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." 1. This is a much more expansive list of situations where ICANN would not have to use the Predictability Model. 2. 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." Thoughts? [cid:image003.png@01D6AEF0.2589CBE0] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com
Jeff, 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@icann.org> On Behalf Of Jeff Neuman Sent: Friday, October 30, 2020 4:09 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] ICANN's Ability to Act (Without Using Predictability Model) [EXTERNAL] ________________________________ All. On the last cast, towards the end of the call, when dealing with Systems (Topic 14)<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1YQ...>, 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." Discussion - 1. Under Predictability (Topic 2)<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpRy...>, 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/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1YQ...>, 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." Thoughts? [cid:image002.png@01D6AEDA.D88CAD90] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://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.
On 30 Oct 2020, at 20:37, Aikman-Scalese, Anne <AAikman@lrrc.com> wrote:
Jeff, 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.”
A security issue in the subsequent procedures program does not equate to a security and stability issue on the Internet identifiers system. For instance, when TAS had a breach, only new gTLD applicants and their information were affected. As for the fiduciary duty to the corporation, its bylaws also foresee it acting in the public interest. So it's somewhat different from a corporation where the Board only has to do what's better for the corporation; so while existential threats to the corporation will require board members to preserve the corporation, even an action by a board member that creates more requirements to the corporation but fulfil its bylaw objectives are aligned with their fiduciary duties. I don't see this workgroup or the GNSO creating new missions for the Empowered Community; I see only EC itself being able to do so. Rubens
I agree with Rubens and prefer Jeff's proposed text. It behoves ICANN to inform impacted users of the affected system(s) so they can determine/take the necessary action in consequence. I can understand possible uncertainty over who such "impacted users" might be depending on the "affected system(s)" but I don't see the need to explicitly mention the Empowered Community representatives here. Justine On Sat, 31 Oct 2020 at 09:40, Rubens Kuhl <rubensk@nic.br> wrote:
On 30 Oct 2020, at 20:37, Aikman-Scalese, Anne <AAikman@lrrc.com> wrote:
Jeff, 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.”
A security issue in the subsequent procedures program does not equate to a security and stability issue on the Internet identifiers system. For instance, when TAS had a breach, only new gTLD applicants and their information were affected.
As for the fiduciary duty to the corporation, its bylaws also foresee it acting in the public interest. So it's somewhat different from a corporation where the Board only has to do what's better for the corporation; so while existential threats to the corporation will require board members to preserve the corporation, even an action by a board member that creates more requirements to the corporation but fulfil its bylaw objectives are aligned with their fiduciary duties.
I don't see this workgroup or the GNSO creating new missions for the Empowered Community; I see only EC itself being able to do so.
Rubens
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ 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.
Thanks All. Rubens and Justine are right in that we are not talking here about the security and stability of the DNS. We are talking about the Application systems themselves. If the Application System is down, or the system to file comments or objections, etc., yes applicants and the applicable system users (commenters, objectors) would be impacted. But the everyday Internet user who doesn’t even know or care about who ICANN and IANA are will not be affected even in the slightest. Therefore, this would not be an Empowered Community thing. Plus, if you look at the difference between the wording of what ICANN Org stated (notice it was not the ICANN Board that stated this in their comments, but rather the Organization), it was to reserve the right to unilaterally take any action “related to security and stability as well as the proper functioning of systems” without going through the Predictability Model. They don’t state the proper functioning of the “Internet Systems” which Anne rewrites below, but just of the “systems” themselves [referring to application systems]. That is an important distinction. So, for those trying to keep track, the proposal is to add the following: “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:image001.png@01D6B086.91824BF0] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Justine Chew Sent: Friday, October 30, 2020 9:53 PM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] ICANN's Ability to Act (Without Using Predictability Model) I agree with Rubens and prefer Jeff's proposed text. It behoves ICANN to inform impacted users of the affected system(s) so they can determine/take the necessary action in consequence. I can understand possible uncertainty over who such "impacted users" might be depending on the "affected system(s)" but I don't see the need to explicitly mention the Empowered Community representatives here. Justine On Sat, 31 Oct 2020 at 09:40, Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>> wrote: On 30 Oct 2020, at 20:37, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Jeff, 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.” A security issue in the subsequent procedures program does not equate to a security and stability issue on the Internet identifiers system. For instance, when TAS had a breach, only new gTLD applicants and their information were affected. As for the fiduciary duty to the corporation, its bylaws also foresee it acting in the public interest. So it's somewhat different from a corporation where the Board only has to do what's better for the corporation; so while existential threats to the corporation will require board members to preserve the corporation, even an action by a board member that creates more requirements to the corporation but fulfil its bylaw objectives are aligned with their fiduciary duties. I don't see this workgroup or the GNSO creating new missions for the Empowered Community; I see only EC itself being able to do so. Rubens _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org<mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ 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.
participants (4)
-
Aikman-Scalese, Anne -
Jeff Neuman -
Justine Chew -
Rubens Kuhl