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
