Re: [Area 4] Business Constituency Stress Test #1
Eric, It's far to early to be trying to winnow this list down given both the charter and practical concerns. This process should not be backward looking, except for inspiration, and should not be limiting except in cases where accounting for a particular scenario causes undo conflict. There might come a moment to be reductive, when conflicts occur but that time is not now. You yourself suggested the possibility of bias with respect to the BC and I think we're seeing it. These scenarios have been the platform from which this very concept has been launched and are due some deference. We can discuss further on the call but for now, let's keep the BC stress tests in the inventory. Thank you. Jonathan Jonathan Zuck President ACT: The App Association Www.ACTonline.org<http://www.ACTonline.org> Eric — there is no need to assign probabilities for contingencies or for consequences. I refer you to the charter for our CCWG<https://community.icann.org/display/acctcrosscomm/Charter>, regarding scenarios: Review of possible solutions for each Work Stream including stress tests against identified contingencies. The CCWG-Accountability should consider the following methodology for stress tests analysis of potential weaknesses and risks analysis existing remedies and their robustness definition of additional remedies or modification of existing remedies description how the proposed solutions would mitigate the risk of contingencies or protect the organization against such contingencies CCWG-Accountability must structure its work to ensure that stress tests can be (i) designed (ii) carried out and (iii) its results being analyzed timely before the transition. Stick to our charter, and we’ll be fine. —Steve From: Eric Brunner-Williams <ebw at abenaki.wabanaki.net<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ebw at abenaki.wabanaki.net<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Date: Sunday, January 11, 2015 at 8:24 PM To: Steve DelBianco <sdelbianco at netchoice.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:sdelbianco at netchoice.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, Mathieu Weill <mathieu.weill at afnic.fr<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:mathieu.weill at afnic.fr<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, Thomas Rickert <rickert at anwaelte.de<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:rickert at anwaelte.de<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, "\"leonfelipe at sanchez.mx<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:leonfelipe at sanchez.mx<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>> >> León Felipe Sánchez Ambía\"" <leonfelipe at sanchez.mx<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:leonfelipe at sanchez.mx<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Cc: "ccwg-accountability4 at icann.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ccwg-accountability4 at icann.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>" <ccwg-accountability4 at icann.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ccwg-accountability4 at icann.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Subject: Re: Business Constituency Stress Test #1 Steve, At some point in this exercise we must assign probabilities for contingencies, as well as for their hypothetical consequences. Would you be so kind as to convey the Business Constituency's assigned probability for: 1. termination of the AoC between the USG and the incumbent contractor, by the USG, while leaving the IANA Functions contract otherwise unchanged? 2. termination of the AoC between the USG and the Corporation, by the Corporation, while retaining the IANA Functions contract otherwise unchanged? Sincerely, Eric Brunner-Williams Eugene, Oregon On 1/11/15 12:27 PM, Steve DelBianco wrote: Eric — I think we have a fundamental disconnect on the meaning and purpose of stress tests. You keep asking about past events, or about why we believe a scenario WOULD happen. But the purpose of scenarios/stress tests is to design plausible situations that help us test accountability mechanisms we have now or are proposing to create. Stress tests are not predictive. We do not need to justify a scenario, or show why it is likely to happen. Nor do we want to be preoccupied with past events. Indeed, the benefit of doing future scenarios is that we avoid fighting over our differing interpretations of past events. As a software guy, you need more than high-level principles to develop an application. Programming requires anticipating scenarios where users don't follow the expected routine. For non-programmers, here's an analogy: It's a good principle to practice safe driving in winter weather. It's a scenario to prepare for and respond to a specific situation, such as having your car spin sideways on a snow-covered road.
Jonathan, I've arranged with the co-chairs to find a replacement liaison. You're free to volunteer. Eric Brunner-Williams Eugene, Oregon On 1/12/15 12:18 PM, Jonathan Zuck wrote:
Eric, It's far to early to be trying to winnow this list down given both the charter and practical concerns. This process should not be backward looking, except for inspiration, and should not be limiting except in cases where accounting for a particular scenario causes undo conflict. There might come a moment to be reductive, when conflicts occur but that time is not now. You yourself suggested the possibility of bias with respect to the BC and I think we're seeing it. These scenarios have been the platform from which this very concept has been launched and are due some deference. We can discuss further on the call but for now, let's keep the BC stress tests in the inventory. Thank you. Jonathan
Jonathan Zuck President ACT: The App Association Www.ACTonline.org <http://www.ACTonline.org>
Eric — there is no need to assign probabilities for contingencies or for consequences. I refer you to the charter for our CCWG<_https://community.icann.org/display/acctcrosscomm/Charter_>, regarding scenarios:
Review of possible solutions for each Work Stream including stress tests against identified contingencies. The CCWG-Accountability should consider the following methodology for stress tests analysis of potential weaknesses and risks analysis existing remedies and their robustness definition of additional remedies or modification of existing remedies description how the proposed solutions would mitigate the risk of contingencies or protect the organization against such contingencies CCWG-Accountability must structure its work to ensure that stress tests can be (i) designed (ii) carried out and (iii) its results being analyzed timely before the transition.
Stick to our charter, and we’ll be fine. —Steve
From: Eric Brunner-Williams <_ebw at abenaki.wabanaki.net_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:_ebw at abenaki.wabanaki.net_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Date: Sunday, January 11, 2015 at 8:24 PM To: Steve DelBianco <_sdelbianco at netchoice.org_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:_sdelbianco at netchoice.org_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, Mathieu Weill <_mathieu.weill at afnic.fr_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:_mathieu.weill at afnic.fr_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, Thomas Rickert <_rickert at anwaelte.de_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:_rickert at anwaelte.de_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, "\"_leonfelipe at sanchez.mx_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:_leonfelipe at sanchez.mx_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>> >> León Felipe Sánchez Ambía\"" <_leonfelipe at sanchez.mx_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:_leonfelipe at sanchez.mx_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Cc: "_ccwg-accountability4 at icann.org_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:_ccwg-accountability4 at icann.org_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>" <_ccwg-accountability4 at icann.org_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:_ccwg-accountability4 at icann.org_ <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Subject: Re: Business Constituency Stress Test #1
Steve,
At some point in this exercise we must assign probabilities for contingencies, as well as for their hypothetical consequences.
Would you be so kind as to convey the Business Constituency's assigned probability for:
1. termination of the AoC between the USG and the incumbent contractor, by the USG, while leaving the IANA Functions contract otherwise unchanged?
2. termination of the AoC between the USG and the Corporation, by the Corporation, while retaining the IANA Functions contract otherwise unchanged?
Sincerely,
Eric Brunner-Williams Eugene, Oregon
On 1/11/15 12:27 PM, Steve DelBianco wrote: Eric — I think we have a fundamental disconnect on the meaning and purpose of stress tests. You keep asking about past events, or about why we believe a scenario WOULD happen.
But the purpose of scenarios/stress tests is to design plausible situations that help us test accountability mechanisms we have now or are proposing to create. Stress tests are not predictive. We do not need to justify a scenario, or show why it is likely to happen.
Nor do we want to be preoccupied with past events. Indeed, the benefit of doing future scenarios is that we avoid fighting over our differing interpretations of past events.
As a software guy, you need more than high-level principles to develop an application. Programming requires anticipating scenarios where users don't follow the expected routine. For non-programmers, here's an analogy: It's a good principle to practice safe driving in winter weather. It's a scenario to prepare for and respond to a specific situation, such as having your car spin sideways on a snow-covered road.
_______________________________________________ Ccwg-accountability4 mailing list Ccwg-accountability4@icann.org https://mm.icann.org/mailman/listinfo/ccwg-accountability4
Colleagues, During yesterday's ConCall Sivasubramanian M provided a link to a set of contingencies / scenarios he is managing. For my own purposes I've used some of each of his contingencies / scenarios to form a short, and possibly relevant identifier. This note is simply informative, providing the URL of the original, below my personal short identifiers, to allow Mr. Sivasubramanian to know that I'm reading his document, and to provide you all with the URL for your own purposes. Eric Brunner-Williams Eugene, Oregon 1 Cancellation of the AoC 2 Flight to avoid jurisdiction 3 Insolvency 4 Applicant Support Revisited 5 Ignoring SSAC 6 GAC Votes 7 .xxx redux 8 Contested gTLD Redelegation 9 Enjoined Delegation 10 Contested ccTLD Redelegation 11 Governmental sanctions and restrictions 12 Domain industry financial crisis 13 Significant financial contributor fee escrow 14 Competing new technology 15 Governance crisis 16 Major corruption or fraud 17 Antitrust or class action 18 Chairman, CEO or major officer conduct 19 Major personal data leak 20 Financial crisis affecting Icann's reserves 21 IANA Customer Standing Committee (CSC) failure 22 IANA Periodic Review Team (PRT) failure 23 Current IANA functions operator threatens litigation 24 A stakeholder captures a multi-stakeholder committee 25 A stakeholder ensures overwhelming control of processes 26 A country captures the process of the PRT 27 Members of the PRT have their lives threatened 28 The PRT is overwhelmed with complaints 29 Terrible appeals judgments by Independent Appeals Panel 30 Current IANA functions operator threatens litigation 31 Rogue Board 32 Rogue Employees 33 Contracting Entity refuses to follow policy or instructions from PRT 34 Operator goes rogue 35 ALAC and GNSO do not see eye to eye 36 ccTLDs and gTLDs strongly disagree 37 ccTLDs that are not part of ICANN oppose ccTLD policies and programs 38 Escalated conflicts between ICANN Board and Staff 39 Nomcom is highly politicized 40 NTIA holds off transferring control until all conditions are met https://docs.google.com/document/d/1QVC12Q-NuB35pyaBirUDF85DBR_oFHkEYC5vbWu0...
Thank You Eric. I have added four more scenarios and wrote down some preventive / mitigation pointers. Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Wed, Jan 14, 2015 at 1:04 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Colleagues,
During yesterday's ConCall Sivasubramanian M provided a link to a set of contingencies / scenarios he is managing. For my own purposes I've used some of each of his contingencies / scenarios to form a short, and possibly relevant identifier.
This note is simply informative, providing the URL of the original, below my personal short identifiers, to allow Mr. Sivasubramanian to know that I'm reading his document, and to provide you all with the URL for your own purposes.
Eric Brunner-Williams Eugene, Oregon
1 Cancellation of the AoC 2 Flight to avoid jurisdiction 3 Insolvency 4 Applicant Support Revisited 5 Ignoring SSAC 6 GAC Votes 7 .xxx redux 8 Contested gTLD Redelegation 9 Enjoined Delegation 10 Contested ccTLD Redelegation 11 Governmental sanctions and restrictions 12 Domain industry financial crisis 13 Significant financial contributor fee escrow 14 Competing new technology 15 Governance crisis 16 Major corruption or fraud 17 Antitrust or class action 18 Chairman, CEO or major officer conduct 19 Major personal data leak 20 Financial crisis affecting Icann's reserves 21 IANA Customer Standing Committee (CSC) failure 22 IANA Periodic Review Team (PRT) failure 23 Current IANA functions operator threatens litigation 24 A stakeholder captures a multi-stakeholder committee 25 A stakeholder ensures overwhelming control of processes 26 A country captures the process of the PRT 27 Members of the PRT have their lives threatened 28 The PRT is overwhelmed with complaints 29 Terrible appeals judgments by Independent Appeals Panel 30 Current IANA functions operator threatens litigation 31 Rogue Board 32 Rogue Employees 33 Contracting Entity refuses to follow policy or instructions from PRT 34 Operator goes rogue 35 ALAC and GNSO do not see eye to eye 36 ccTLDs and gTLDs strongly disagree 37 ccTLDs that are not part of ICANN oppose ccTLD policies and programs 38 Escalated conflicts between ICANN Board and Staff 39 Nomcom is highly politicized 40 NTIA holds off transferring control until all conditions are met
https://docs.google.com/document/d/1QVC12Q-NuB35pyaBirUDF85DBR_ oFHkEYC5vbWu04go/edit#heading=h.rraejy2i0t2g
Siva, I'll pick those up tomorrow. Could you confirm who the authors of these are, e.g., the "Olivier", the "Robert", etc., in case there is a need for clarification. Thanks in advance, Eric On 1/13/15 12:40 PM, Sivasubramanian M wrote:
Thank You Eric. I have added four more scenarios and wrote down some preventive / mitigation pointers.
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Wed, Jan 14, 2015 at 1:04 AM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net <mailto:ebw@abenaki.wabanaki.net>> wrote:
Colleagues,
During yesterday's ConCall Sivasubramanian M provided a link to a set of contingencies / scenarios he is managing. For my own purposes I've used some of each of his contingencies / scenarios to form a short, and possibly relevant identifier.
This note is simply informative, providing the URL of the original, below my personal short identifiers, to allow Mr. Sivasubramanian to know that I'm reading his document, and to provide you all with the URL for your own purposes.
Eric Brunner-Williams Eugene, Oregon
1 Cancellation of the AoC 2 Flight to avoid jurisdiction 3 Insolvency 4 Applicant Support Revisited 5 Ignoring SSAC 6 GAC Votes 7 .xxx redux 8 Contested gTLD Redelegation 9 Enjoined Delegation 10 Contested ccTLD Redelegation 11 Governmental sanctions and restrictions 12 Domain industry financial crisis 13 Significant financial contributor fee escrow 14 Competing new technology 15 Governance crisis 16 Major corruption or fraud 17 Antitrust or class action 18 Chairman, CEO or major officer conduct 19 Major personal data leak 20 Financial crisis affecting Icann's reserves 21 IANA Customer Standing Committee (CSC) failure 22 IANA Periodic Review Team (PRT) failure 23 Current IANA functions operator threatens litigation 24 A stakeholder captures a multi-stakeholder committee 25 A stakeholder ensures overwhelming control of processes 26 A country captures the process of the PRT 27 Members of the PRT have their lives threatened 28 The PRT is overwhelmed with complaints 29 Terrible appeals judgments by Independent Appeals Panel 30 Current IANA functions operator threatens litigation 31 Rogue Board 32 Rogue Employees 33 Contracting Entity refuses to follow policy or instructions from PRT 34 Operator goes rogue 35 ALAC and GNSO do not see eye to eye 36 ccTLDs and gTLDs strongly disagree 37 ccTLDs that are not part of ICANN oppose ccTLD policies and programs 38 Escalated conflicts between ICANN Board and Staff 39 Nomcom is highly politicized 40 NTIA holds off transferring control until all conditions are met
https://docs.google.com/document/d/1QVC12Q-NuB35pyaBirUDF85DBR_oFHkEYC5vbWu0...
Thanks Eric. Did some more work. The authors are: Olivier Crepin-LeBlond Robert Guerra Business Constituency Mathieu Weill SSAC Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Wed, Jan 14, 2015 at 6:44 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Siva,
I'll pick those up tomorrow. Could you confirm who the authors of these are, e.g., the "Olivier", the "Robert", etc., in case there is a need for clarification.
Thanks in advance, Eric
On 1/13/15 12:40 PM, Sivasubramanian M wrote:
Thank You Eric. I have added four more scenarios and wrote down some preventive / mitigation pointers.
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Wed, Jan 14, 2015 at 1:04 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Colleagues,
During yesterday's ConCall Sivasubramanian M provided a link to a set of contingencies / scenarios he is managing. For my own purposes I've used some of each of his contingencies / scenarios to form a short, and possibly relevant identifier.
This note is simply informative, providing the URL of the original, below my personal short identifiers, to allow Mr. Sivasubramanian to know that I'm reading his document, and to provide you all with the URL for your own purposes.
Eric Brunner-Williams Eugene, Oregon
1 Cancellation of the AoC 2 Flight to avoid jurisdiction 3 Insolvency 4 Applicant Support Revisited 5 Ignoring SSAC 6 GAC Votes 7 .xxx redux 8 Contested gTLD Redelegation 9 Enjoined Delegation 10 Contested ccTLD Redelegation 11 Governmental sanctions and restrictions 12 Domain industry financial crisis 13 Significant financial contributor fee escrow 14 Competing new technology 15 Governance crisis 16 Major corruption or fraud 17 Antitrust or class action 18 Chairman, CEO or major officer conduct 19 Major personal data leak 20 Financial crisis affecting Icann's reserves 21 IANA Customer Standing Committee (CSC) failure 22 IANA Periodic Review Team (PRT) failure 23 Current IANA functions operator threatens litigation 24 A stakeholder captures a multi-stakeholder committee 25 A stakeholder ensures overwhelming control of processes 26 A country captures the process of the PRT 27 Members of the PRT have their lives threatened 28 The PRT is overwhelmed with complaints 29 Terrible appeals judgments by Independent Appeals Panel 30 Current IANA functions operator threatens litigation 31 Rogue Board 32 Rogue Employees 33 Contracting Entity refuses to follow policy or instructions from PRT 34 Operator goes rogue 35 ALAC and GNSO do not see eye to eye 36 ccTLDs and gTLDs strongly disagree 37 ccTLDs that are not part of ICANN oppose ccTLD policies and programs 38 Escalated conflicts between ICANN Board and Staff 39 Nomcom is highly politicized 40 NTIA holds off transferring control until all conditions are met
https://docs.google.com/document/d/1QVC12Q-NuB35pyaBirUDF85DBR_oFHkEYC5vbWu0...
Siva, Thanks again. Is there a reason why Robert is identified separately? Is his contribution (your #40) made separately from those (not yet present in your list) made by the SSAC? Eric On 1/13/15 5:44 PM, Sivasubramanian M wrote:
Thanks Eric. Did some more work.
The authors are:
Olivier Crepin-LeBlond Robert Guerra Business Constituency Mathieu Weill SSAC
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Wed, Jan 14, 2015 at 6:44 AM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net <mailto:ebw@abenaki.wabanaki.net>> wrote:
Siva,
I'll pick those up tomorrow. Could you confirm who the authors of these are, e.g., the "Olivier", the "Robert", etc., in case there is a need for clarification.
Thanks in advance, Eric
On 1/13/15 12:40 PM, Sivasubramanian M wrote:
Thank You Eric. I have added four more scenarios and wrote down some preventive / mitigation pointers.
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Wed, Jan 14, 2015 at 1:04 AM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net <mailto:ebw@abenaki.wabanaki.net>> wrote:
Colleagues,
During yesterday's ConCall Sivasubramanian M provided a link to a set of contingencies / scenarios he is managing. For my own purposes I've used some of each of his contingencies / scenarios to form a short, and possibly relevant identifier.
This note is simply informative, providing the URL of the original, below my personal short identifiers, to allow Mr. Sivasubramanian to know that I'm reading his document, and to provide you all with the URL for your own purposes.
Eric Brunner-Williams Eugene, Oregon
1 Cancellation of the AoC 2 Flight to avoid jurisdiction 3 Insolvency 4 Applicant Support Revisited 5 Ignoring SSAC 6 GAC Votes 7 .xxx redux 8 Contested gTLD Redelegation 9 Enjoined Delegation 10 Contested ccTLD Redelegation 11 Governmental sanctions and restrictions 12 Domain industry financial crisis 13 Significant financial contributor fee escrow 14 Competing new technology 15 Governance crisis 16 Major corruption or fraud 17 Antitrust or class action 18 Chairman, CEO or major officer conduct 19 Major personal data leak 20 Financial crisis affecting Icann's reserves 21 IANA Customer Standing Committee (CSC) failure 22 IANA Periodic Review Team (PRT) failure 23 Current IANA functions operator threatens litigation 24 A stakeholder captures a multi-stakeholder committee 25 A stakeholder ensures overwhelming control of processes 26 A country captures the process of the PRT 27 Members of the PRT have their lives threatened 28 The PRT is overwhelmed with complaints 29 Terrible appeals judgments by Independent Appeals Panel 30 Current IANA functions operator threatens litigation 31 Rogue Board 32 Rogue Employees 33 Contracting Entity refuses to follow policy or instructions from PRT 34 Operator goes rogue 35 ALAC and GNSO do not see eye to eye 36 ccTLDs and gTLDs strongly disagree 37 ccTLDs that are not part of ICANN oppose ccTLD policies and programs 38 Escalated conflicts between ICANN Board and Staff 39 Nomcom is highly politicized 40 NTIA holds off transferring control until all conditions are met
https://docs.google.com/document/d/1QVC12Q-NuB35pyaBirUDF85DBR_oFHkEYC5vbWu0...
Dear Eric Brunner-Williams, If you are referring to the Scenarios shown in the third column, Item # 40 is a scenario outlined by Robert Guerra. Here is the complete list BC - # 1 - 10 SSAC # 11 Weill # 12-20 (Can't find the email / document where Weill had outlined these scenarios. Robert, do you have the original mail from Weill that listed 12-20, please ? ) Olivier # 21 -34 Siva # 35-39 Robert # 40 Siva # 41- 45 As for the mitigation options, Olivier's options are copied against 29 -32, I started outlining some preventive / mitigation strategies for the rest of the scenarios and waiting for participation. Thank you Sivasubramanian M Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Wed, Jan 14, 2015 at 8:09 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Siva,
Thanks again. Is there a reason why Robert is identified separately? Is his contribution (your #40) made separately from those (not yet present in your list) made by the SSAC?
Eric
On 1/13/15 5:44 PM, Sivasubramanian M wrote:
Thanks Eric. Did some more work.
The authors are:
Olivier Crepin-LeBlond Robert Guerra Business Constituency Mathieu Weill SSAC
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Wed, Jan 14, 2015 at 6:44 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Siva,
I'll pick those up tomorrow. Could you confirm who the authors of these are, e.g., the "Olivier", the "Robert", etc., in case there is a need for clarification.
Thanks in advance, Eric
On 1/13/15 12:40 PM, Sivasubramanian M wrote:
Thank You Eric. I have added four more scenarios and wrote down some preventive / mitigation pointers.
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Wed, Jan 14, 2015 at 1:04 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Colleagues,
During yesterday's ConCall Sivasubramanian M provided a link to a set of contingencies / scenarios he is managing. For my own purposes I've used some of each of his contingencies / scenarios to form a short, and possibly relevant identifier.
This note is simply informative, providing the URL of the original, below my personal short identifiers, to allow Mr. Sivasubramanian to know that I'm reading his document, and to provide you all with the URL for your own purposes.
Eric Brunner-Williams Eugene, Oregon
1 Cancellation of the AoC 2 Flight to avoid jurisdiction 3 Insolvency 4 Applicant Support Revisited 5 Ignoring SSAC 6 GAC Votes 7 .xxx redux 8 Contested gTLD Redelegation 9 Enjoined Delegation 10 Contested ccTLD Redelegation 11 Governmental sanctions and restrictions 12 Domain industry financial crisis 13 Significant financial contributor fee escrow 14 Competing new technology 15 Governance crisis 16 Major corruption or fraud 17 Antitrust or class action 18 Chairman, CEO or major officer conduct 19 Major personal data leak 20 Financial crisis affecting Icann's reserves 21 IANA Customer Standing Committee (CSC) failure 22 IANA Periodic Review Team (PRT) failure 23 Current IANA functions operator threatens litigation 24 A stakeholder captures a multi-stakeholder committee 25 A stakeholder ensures overwhelming control of processes 26 A country captures the process of the PRT 27 Members of the PRT have their lives threatened 28 The PRT is overwhelmed with complaints 29 Terrible appeals judgments by Independent Appeals Panel 30 Current IANA functions operator threatens litigation 31 Rogue Board 32 Rogue Employees 33 Contracting Entity refuses to follow policy or instructions from PRT 34 Operator goes rogue 35 ALAC and GNSO do not see eye to eye 36 ccTLDs and gTLDs strongly disagree 37 ccTLDs that are not part of ICANN oppose ccTLD policies and programs 38 Escalated conflicts between ICANN Board and Staff 39 Nomcom is highly politicized 40 NTIA holds off transferring control until all conditions are met
https://docs.google.com/document/d/1QVC12Q-NuB35pyaBirUDF85DBR_oFHkEYC5vbWu0...
Siva, As a personal courtesy I would appreciate answers to few questions. In #23, in the phrase "the current IANA functions operator" might refer to some point in the future, e.g., after 2017, at which the IANA Functions might be conducted by some party other than the current contractor (ICANN), or it might refer to the current 2015 contractor (ICANN). It might be useful to clarify which, some entity not at present the IANA Functions contractor, or the present IANA Functions contractor, is hypothesized as litigating to prevent a change of the IANA Functions contract operator. What appears to be the same scenario appears, with more language, at #30. In #33, the Periodic Review Teams (PRT) sues the "Iana Contracting Entity". In neither the current Bylaws, Article IV, Section 4, which contains provisions for "periodic review", and subordinate documents (Methodology, Systematization, etc.), nor in the Affirmation of Commitments can I find a delegation of legal incorporation authority to a Review Team. It might be useful to clarify which Review Teams may form legal persons and "sue" some third-party, e.g., the current 2015 IANA Functions contractor (ICANN), and where this standing arises. In #26, #27 and #28, a Periodic Review Team appears to periodically select awardee(s) to one or more successor(s) to the current IANA Functions Contract. Is this a correct reading of these scenarios? If so, as with #33, it might be useful to clarify where the authority to award the successor(s) to the current IANA Functions Contract arises. I've copied the WS4 list simply to create a record of these questions outside of my cluttered mailer's archives, and "I don't know" is a reasonable answer, as these are among Olivier Crepin-LeBlond's contributions. Thanks in advance, Eric Brunner-Williams
Dear Eric, On Thu, Jan 15, 2015 at 12:07 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Siva,
As a personal courtesy I would appreciate answers to few questions.
In #23, in the phrase "the current IANA functions operator" might refer to some point in the future, e.g., after 2017, at which the IANA Functions might be conducted by some party other than the current contractor (ICANN), or it might refer to the current 2015 contractor (ICANN).
It might be useful to clarify which, some entity not at present the IANA Functions contractor, or the present IANA Functions contractor, is hypothesized as litigating to prevent a change of the IANA Functions contract operator.
These are imaginary scenarios, not to be read as alluding to a real, existing or anticipated threat. In this imaginary scenario, "the current IANA functions operator" refers to the present IANA functions operator, rather impersonally. The preventive / mitigation strategy mentioned points to this imaginary scenario of a threat of litigation from the present IANA operator.
What appears to be the same scenario appears, with more language, at #30.
In #33, the Periodic Review Teams (PRT) sues the "Iana Contracting Entity". In neither the current Bylaws, Article IV, Section 4, which contains provisions for "periodic review", and subordinate documents (Methodology, Systematization, etc.), nor in the Affirmation of Commitments can I find a delegation of legal incorporation authority to a Review Team.
It might be useful to clarify which Review Teams may form legal persons and "sue" some third-party, e.g., the current 2015 IANA Functions contractor (ICANN), and where this standing arises.
In #26, #27 and #28, a Periodic Review Team appears to periodically select awardee(s) to one or more successor(s) to the current IANA Functions Contract. Is this a correct reading of these scenarios? If so, as with #33, it might be useful to clarify where the authority to award the successor(s) to the current IANA Functions Contract arises.
Olivier came up with scenario s 26, 27, 28 as well as 33 among a few others . He would be in a better position to clarify. The message is copied to him.
I've copied the WS4 list simply to create a record of these questions outside of my cluttered mailer's archives, and "I don't know" is a reasonable answer, as these are among Olivier Crepin-LeBlond's contributions.
Thanks in advance, Eric Brunner-Williams
Siva, Thanks for the clarification.
... this imaginary scenario of a threat of litigation from the present IANA operator.
In this scenario, who is ICANN suing?
Olivier came up with scenario s 26, 27, 28 as well as 33 among a few others . He would be in a better position to clarify. The message is copied to him.
I look forward to his response, if any. Again, as a personal courtesy. Again, my thanks. Eric Brunner-Williams Eugene, Oregon
Dear Eric, The IANA operator refers to the present IANA technical services backend. It is not ICANN that is visualized as threatening legal action or suing. The scenario is that of the backend operator suing ICANN. Thanks. Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Thu, Jan 15, 2015 at 2:13 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Siva,
Thanks for the clarification.
... this imaginary scenario of a threat of litigation from the present IANA operator.
In this scenario, who is ICANN suing?
Olivier came up with scenario s 26, 27, 28 as well as 33 among a few others . He would be in a better position to clarify. The message is copied to him.
I look forward to his response, if any. Again, as a personal courtesy.
Again, my thanks.
Eric Brunner-Williams Eugene, Oregon
Dear Siva, I was not aware that the IANA Function is currently being conducted by an operator legally distinct from ICANN. In fact, I'm surprised by this, having worked for the IANA in 2007 and know many of the staff who report to Elise Gerich, V.P., IANA & Technical Operations. When did this outsourcing take place, or am I misunderstanding and the scenario is positing that at some future point in time ICANN (or its successor in interest) will outsource to a "backend operator", and this "backend operator" will subsequently sue ICANN (or its successor in interest) for the purposes of remaining the incumbent "backend operator"? I think this is the last question I will ask about #23. Thanks again, and I appreciate that this is one of Olivier's scenarios, so "I don't know" would be quite understandable, and any response would be appreciated as a personal courtesy, again, with the WS4 list copied only to provide a record of the question. Eric Brunner-Williams Eugene, Oregon On 1/14/15 1:19 PM, Sivasubramanian M wrote:
Dear Eric,
The IANA operator refers to the present IANA technical services backend. It is not ICANN that is visualized as threatening legal action or suing. The scenario is that of the backend operator suing ICANN.
Thanks.
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Thu, Jan 15, 2015 at 2:13 AM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net <mailto:ebw@abenaki.wabanaki.net>> wrote:
Siva,
Thanks for the clarification.
... this imaginary scenario of a threat of litigation from the present IANA operator.
In this scenario, who is ICANN suing?
Olivier came up with scenario s 26, 27, 28 as well as 33 among a few others . He would be in a better position to clarify. The message is copied to him.
I look forward to his response, if any. Again, as a personal courtesy.
Again, my thanks.
Eric Brunner-Williams Eugene, Oregon
I am sorry Eric.. My understanding is that the expression "IANA operator" referred to Verisign. So I though that the scearaio pertained to Verisign Contract rather than the NTIA like contract to IANA. Will wait for a clarification from Olivier and then correct the response in the spreadsheet Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Thu, Jan 15, 2015 at 4:37 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Dear Siva,
I was not aware that the IANA Function is currently being conducted by an operator legally distinct from ICANN. In fact, I'm surprised by this, having worked for the IANA in 2007 and know many of the staff who report to Elise Gerich, V.P., IANA & Technical Operations. When did this outsourcing take place, or am I misunderstanding and the scenario is positing that at some future point in time ICANN (or its successor in interest) will outsource to a "backend operator", and this "backend operator" will subsequently sue ICANN (or its successor in interest) for the purposes of remaining the incumbent "backend operator"?
I think this is the last question I will ask about #23.
Thanks again, and I appreciate that this is one of Olivier's scenarios, so "I don't know" would be quite understandable, and any response would be appreciated as a personal courtesy, again, with the WS4 list copied only to provide a record of the question.
Eric Brunner-Williams Eugene, Oregon
On 1/14/15 1:19 PM, Sivasubramanian M wrote:
Dear Eric,
The IANA operator refers to the present IANA technical services backend. It is not ICANN that is visualized as threatening legal action or suing. The scenario is that of the backend operator suing ICANN.
Thanks.
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Thu, Jan 15, 2015 at 2:13 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Siva,
Thanks for the clarification.
... this imaginary scenario of a threat of litigation from the present IANA operator.
In this scenario, who is ICANN suing?
Olivier came up with scenario s 26, 27, 28 as well as 33 among a few others . He would be in a better position to clarify. The message is copied to him.
I look forward to his response, if any. Again, as a personal courtesy.
Again, my thanks.
Eric Brunner-Williams Eugene, Oregon
Hello all, On 14/01/2015 23:07, Eric Brunner-Williams wrote:
I think this is the last question I will ask about #23.
Sorry I came a little late on this but I think I explained my thinking in a message just a moment ago. I was *not* speaking about the back-end operator. I was speaking about the "IANA operator" thus ICANN at present. Kind regards, Olivier
Thanks for the clarification. Sivasubramanian M Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Thu, Jan 15, 2015 at 5:00 AM, Olivier MJ Crepin-Leblond <ocl@gih.com> wrote:
Hello all,
On 14/01/2015 23:07, Eric Brunner-Williams wrote:
I think this is the last question I will ask about #23.
Sorry I came a little late on this but I think I explained my thinking in a message just a moment ago. I was *not* speaking about the back-end operator. I was speaking about the "IANA operator" thus ICANN at present.
Kind regards,
Olivier
I asked (up thread):
In this scenario, who is ICANN suing?
I see. After (assuming it happens) the transition from the current NTIA-ICANN fact pattern, in some subsequent future transition, from a situation we don't yet know to some other situation we also don't yet know, the current ICANN, hypothesized to be the IANA Functions operator after the current contract (and possibly its one, or two extensions), will sue some other entity to prevent that other entity from becoming the IANA Functions operator. I'm clear now. The scenario addresses a potential transition after the transition-possibly-in-progress. Thanks for the clarification. Eric Brunner-Williams Eugene, Oregon On 1/14/15 3:30 PM, Olivier MJ Crepin-Leblond wrote:
Hello all,
On 14/01/2015 23:07, Eric Brunner-Williams wrote:
I think this is the last question I will ask about #23. Sorry I came a little late on this but I think I explained my thinking in a message just a moment ago. I was *not* speaking about the back-end operator. I was speaking about the "IANA operator" thus ICANN at present.
Kind regards,
Olivier
I think that before we conclude on "identify[ing] the main contingencies that CCWG Accountability will use to test the proposed mechanisms and solutions, once they are elaborated" we should compare the list we have against comments reviewed by Area 2, to ensure that there weren't things identified there that we ought to include here. I've had a first go with some Area 2 items I'm more familiar with. As a result I've added three items and generalised one existing one; see attached. This isn't suggested as being complete. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd 21-27 St Thomas Street, London SE1 9RY Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
Thanks Malcolm... On 19/01/2015 12:37 pm, "Malcolm Hutty" <malcolm@linx.net> wrote:
I think that before we conclude on "identify[ing] the main contingencies that CCWG Accountability will use to test the proposed mechanisms and solutions, once they are elaborated"
we should compare the list we have against comments reviewed by Area 2, to ensure that there weren't things identified there that we ought to include here.
I've had a first go with some Area 2 items I'm more familiar with. As a result I've added three items and generalised one existing one; see attached. This isn't suggested as being complete.
Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/
London Internet Exchange Ltd 21-27 St Thomas Street, London SE1 9RY
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
_______________________________________________ Ccwg-accountability4 mailing list Ccwg-accountability4@icann.org https://mm.icann.org/mailman/listinfo/ccwg-accountability4
Hello Siva and Eric, let me try and explain quickly: On 14/01/2015 20:43, Eric Brunner-Williams wrote:
Siva,
Thanks for the clarification.
... this imaginary scenario of a threat of litigation from the present IANA operator.
In this scenario, who is ICANN suing?
If a Contract Co. was in place, the reallocation of the contract to another operator would likely trigger the existing contract holder, ICANN at present, to sue the Contract Co. In another scenario, any organisation could sue the Contract Co. to hinder its operation.
Olivier came up with scenario s 26, 27, 28 as well as 33 among a few others . He would be in a better position to clarify. The message is copied to him.
I look forward to his response, if any. Again, as a personal courtesy.
PRT => MRT - nomenclature has evolved since I worked on the scenarios. 26: A law is passed or a country gets a court to order an action that bypasses any process in place. An example of such bypassing (but unrelated to the IANA functions) is the closing of .COM domains by the FBI of Web sites that are hosted in another country. 27: pretty explicit. Also - if an MRT was not under the legal umbrella of any organisation, individual MRT members would be liable to litigation on an individual basis. So physical threat is not the only threat. 28: quite explicit 29: Independent Panels have not fared well in the ICANN world. For an example of terrible panel decisions, see the visual similarity panels where .COM was deemed to be confusingly similar to .CAM by one panel and not confusingly similar to .CAM by another panel. 33: the question is if MRT is not a legal body or within a legal body how does it get an independent Contract Co. to abide by its instructions when Contract Co. decides to ignore it I've responded to the numbers listed but would be happy to clarify any other scenario if needed. Kindest regards, Olivier
Oliver / Eric I thought your scenario referred to Verisign which operates IANA ??? If this is not correct, I need to correct my response against this scenario Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Thu, Jan 15, 2015 at 4:47 AM, Olivier MJ Crepin-Leblond <ocl@gih.com> wrote:
Hello Siva and Eric,
let me try and explain quickly:
On 14/01/2015 20:43, Eric Brunner-Williams wrote:
Siva,
Thanks for the clarification.
... this imaginary scenario of a threat of litigation from the present IANA operator.
In this scenario, who is ICANN suing?
If a Contract Co. was in place, the reallocation of the contract to another operator would likely trigger the existing contract holder, ICANN at present, to sue the Contract Co. In another scenario, any organisation could sue the Contract Co. to hinder its operation.
Olivier came up with scenario s 26, 27, 28 as well as 33 among a few others . He would be in a better position to clarify. The message is copied to him.
I look forward to his response, if any. Again, as a personal courtesy.
PRT => MRT - nomenclature has evolved since I worked on the scenarios.
26: A law is passed or a country gets a court to order an action that bypasses any process in place. An example of such bypassing (but unrelated to the IANA functions) is the closing of .COM domains by the FBI of Web sites that are hosted in another country. 27: pretty explicit. Also - if an MRT was not under the legal umbrella of any organisation, individual MRT members would be liable to litigation on an individual basis. So physical threat is not the only threat. 28: quite explicit 29: Independent Panels have not fared well in the ICANN world. For an example of terrible panel decisions, see the visual similarity panels where .COM was deemed to be confusingly similar to .CAM by one panel and not confusingly similar to .CAM by another panel. 33: the question is if MRT is not a legal body or within a legal body how does it get an independent Contract Co. to abide by its instructions when Contract Co. decides to ignore it
I've responded to the numbers listed but would be happy to clarify any other scenario if needed.
Kindest regards,
Olivier
I agree with Jonathan. I was a member of this CCWG Charter’s drafting team and we discussed the need for stress testing on numerous occasions, which is evidenced but the repeated references to them in the Charter itself. At this juncture the scenarios should be all-inclusive so that there can be a robust debate about the appropriate stress tests among CCWG members. Thanks, David From: ccwg-accountability4-bounces@icann.org [mailto:ccwg-accountability4-bounces@icann.org] On Behalf Of Jonathan Zuck Sent: 12 January 2015 20:18 To: ccwg-accountability4 Subject: Re: [Area 4] Business Constituency Stress Test #1 Eric, It's far to early to be trying to winnow this list down given both the charter and practical concerns. This process should not be backward looking, except for inspiration, and should not be limiting except in cases where accounting for a particular scenario causes undo conflict. There might come a moment to be reductive, when conflicts occur but that time is not now. You yourself suggested the possibility of bias with respect to the BC and I think we're seeing it. These scenarios have been the platform from which this very concept has been launched and are due some deference. We can discuss further on the call but for now, let's keep the BC stress tests in the inventory. Thank you. Jonathan Jonathan Zuck President ACT: The App Association Www.ACTonline.org<http://www.ACTonline.org> Eric — there is no need to assign probabilities for contingencies or for consequences. I refer you to the charter for our CCWG<https://community.icann.org/display/acctcrosscomm/Charter>, regarding scenarios: Review of possible solutions for each Work Stream including stress tests against identified contingencies. The CCWG-Accountability should consider the following methodology for stress tests analysis of potential weaknesses and risks analysis existing remedies and their robustness definition of additional remedies or modification of existing remedies description how the proposed solutions would mitigate the risk of contingencies or protect the organization against such contingencies CCWG-Accountability must structure its work to ensure that stress tests can be (i) designed (ii) carried out and (iii) its results being analyzed timely before the transition. Stick to our charter, and we’ll be fine. —Steve From: Eric Brunner-Williams <ebw at abenaki.wabanaki.net<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ebw at abenaki.wabanaki.net<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Date: Sunday, January 11, 2015 at 8:24 PM To: Steve DelBianco <sdelbianco at netchoice.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:sdelbianco at netchoice.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, Mathieu Weill <mathieu.weill at afnic.fr<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:mathieu.weill at afnic.fr<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, Thomas Rickert <rickert at anwaelte.de<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:rickert at anwaelte.de<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, "\"leonfelipe at sanchez.mx<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:leonfelipe at sanchez.mx<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>> >> León Felipe Sánchez Ambía\"" <leonfelipe at sanchez.mx<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:leonfelipe at sanchez.mx<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Cc: "ccwg-accountability4 at icann.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ccwg-accountability4 at icann.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>" <ccwg-accountability4 at icann.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ccwg-accountability4 at icann.org<https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>> Subject: Re: Business Constituency Stress Test #1 Steve, At some point in this exercise we must assign probabilities for contingencies, as well as for their hypothetical consequences. Would you be so kind as to convey the Business Constituency's assigned probability for: 1. termination of the AoC between the USG and the incumbent contractor, by the USG, while leaving the IANA Functions contract otherwise unchanged? 2. termination of the AoC between the USG and the Corporation, by the Corporation, while retaining the IANA Functions contract otherwise unchanged? Sincerely, Eric Brunner-Williams Eugene, Oregon On 1/11/15 12:27 PM, Steve DelBianco wrote: Eric — I think we have a fundamental disconnect on the meaning and purpose of stress tests. You keep asking about past events, or about why we believe a scenario WOULD happen. But the purpose of scenarios/stress tests is to design plausible situations that help us test accountability mechanisms we have now or are proposing to create. Stress tests are not predictive. We do not need to justify a scenario, or show why it is likely to happen. Nor do we want to be preoccupied with past events. Indeed, the benefit of doing future scenarios is that we avoid fighting over our differing interpretations of past events. As a software guy, you need more than high-level principles to develop an application. Programming requires anticipating scenarios where users don't follow the expected routine. For non-programmers, here's an analogy: It's a good principle to practice safe driving in winter weather. It's a scenario to prepare for and respond to a specific situation, such as having your car spin sideways on a snow-covered road. This message and its attachments may contain legally privileged or confidential information. It is intended solely for the named addressee. If you are not the addressee indicated in this message (or responsible for delivery of the message to the addressee), you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments that does not relate to the official business of Twenty-First Century Fox, Inc. or its subsidiaries must be taken not to have been sent or endorsed by any of them. No representation is made that this email or its attachments are without defect.
Dear Leon May you please describe the real difference between a ) and b) and why we need to have two different agreement (A new AoC, or some other kind of document, between ICANN and the community) and . b) (A new AoC or some other kind of document between the IANA functions manager and the community) Does it mean that Iana Function manager would not be part of ICANN . If yes then what the relation between these two ? Kavouss . 2015-01-13 10:22 GMT+01:00 Fares, David <DFares@21cf.com>:
I agree with Jonathan. I was a member of this CCWG Charter’s drafting team and we discussed the need for stress testing on numerous occasions, which is evidenced but the repeated references to them in the Charter itself. At this juncture the scenarios should be all-inclusive so that there can be a robust debate about the appropriate stress tests among CCWG members.
Thanks,
David
*From:* ccwg-accountability4-bounces@icann.org [mailto: ccwg-accountability4-bounces@icann.org] *On Behalf Of *Jonathan Zuck *Sent:* 12 January 2015 20:18 *To:* ccwg-accountability4 *Subject:* Re: [Area 4] Business Constituency Stress Test #1
Eric,
It's far to early to be trying to winnow this list down given both the charter and practical concerns. This process should not be backward looking, except for inspiration, and should not be limiting except in cases where accounting for a particular scenario causes undo conflict. There might come a moment to be reductive, when conflicts occur but that time is not now. You yourself suggested the possibility of bias with respect to the BC and I think we're seeing it. These scenarios have been the platform from which this very concept has been launched and are due some deference. We can discuss further on the call but for now, let's keep the BC stress tests in the inventory. Thank you.
Jonathan
Jonathan Zuck President ACT: The App Association Www.ACTonline.org <http://www.ACTonline.org>
Eric — there is no need to assign probabilities for contingencies or for consequences. I refer you to the charter for our CCWG<https://community.icann.org/display/acctcrosscomm/Charter>, regarding scenarios:
Review of possible solutions for each Work Stream including stress tests against identified contingencies. The CCWG-Accountability should consider the following methodology for stress tests
analysis of potential weaknesses and risks
analysis existing remedies and their robustness
definition of additional remedies or modification of existing remedies
description how the proposed solutions would mitigate the risk of contingencies or protect the organization against such contingencies
CCWG-Accountability must structure its work to ensure that stress tests can be (i) designed (ii) carried out and (iii) its results being analyzed timely before the transition.
Stick to our charter, and we’ll be fine.
—Steve
From: Eric Brunner-Williams <ebw at abenaki.wabanaki.net <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ebw at abenaki.wabanaki.net <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>
Date: Sunday, January 11, 2015 at 8:24 PM
To: Steve DelBianco <sdelbianco at netchoice.org <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:sdelbianco at netchoice.org <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, Mathieu Weill <mathieu.weill at afnic.fr <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:mathieu.weill at afnic.fr <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, Thomas Rickert <rickert at anwaelte.de <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:rickert at anwaelte.de <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>, "\"leonfelipe at sanchez.mx <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:leonfelipe at sanchez.mx <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>> >> León Felipe Sánchez Ambía\"" <leonfelipe at sanchez.mx <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:leonfelipe at sanchez.mx <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>
Cc: "ccwg-accountability4 at icann.org <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ccwg-accountability4 at icann.org <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>" <ccwg-accountability4 at icann.org <https://mm.icann.org/mailman/listinfo/ccwg-accountability4><mailto:ccwg-accountability4 at icann.org <https://mm.icann.org/mailman/listinfo/ccwg-accountability4>>>
Subject: Re: Business Constituency Stress Test #1
Steve,
At some point in this exercise we must assign probabilities for contingencies, as well as for their hypothetical consequences.
Would you be so kind as to convey the Business Constituency's assigned probability for:
1. termination of the AoC between the USG and the incumbent contractor, by the USG, while leaving the IANA Functions contract otherwise unchanged?
2. termination of the AoC between the USG and the Corporation, by the Corporation, while retaining the IANA Functions contract otherwise unchanged?
Sincerely,
Eric Brunner-Williams
Eugene, Oregon
On 1/11/15 12:27 PM, Steve DelBianco wrote:
Eric — I think we have a fundamental disconnect on the meaning and purpose of stress tests. You keep asking about past events, or about why we believe a scenario WOULD happen.
But the purpose of scenarios/stress tests is to design plausible situations that help us test accountability mechanisms we have now or are proposing to create. Stress tests are not predictive. We do not need to justify a scenario, or show why it is likely to happen.
Nor do we want to be preoccupied with past events. Indeed, the benefit of doing future scenarios is that we avoid fighting over our differing interpretations of past events.
As a software guy, you need more than high-level principles to develop an application. Programming requires anticipating scenarios where users don't follow the expected routine. For non-programmers, here's an analogy: It's a good principle to practice safe driving in winter weather. It's a scenario to prepare for and respond to a specific situation, such as having your car spin sideways on a snow-covered road.
This message and its attachments may contain legally privileged or confidential information. It is intended solely for the named addressee. If you are not the addressee indicated in this message (or responsible for delivery of the message to the addressee), you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments that does not relate to the official business of Twenty-First Century Fox, Inc. or its subsidiaries must be taken not to have been sent or endorsed by any of them. No representation is made that this email or its attachments are without defect.
_______________________________________________ Ccwg-accountability4 mailing list Ccwg-accountability4@icann.org https://mm.icann.org/mailman/listinfo/ccwg-accountability4
participants (8)
-
Cheryl Langdon-Orr -
Eric Brunner-Williams -
Fares, David -
Jonathan Zuck -
Kavouss Arasteh -
Malcolm Hutty -
Olivier MJ Crepin-Leblond -
Sivasubramanian M