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

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<mailto:ebw at abenaki.wabanaki.net>>
Date: Sunday, January 11, 2015 at 8:24 PM
To: Steve DelBianco <sdelbianco at netchoice.org<mailto:sdelbianco at netchoice.org>>, Mathieu Weill <mathieu.weill at afnic.fr<mailto:mathieu.weill at afnic.fr>>, Thomas Rickert <rickert at anwaelte.de<mailto:rickert at anwaelte.de>>, "\"leonfelipe at sanchez.mx<mailto:leonfelipe at sanchez.mx> >> León Felipe Sánchez Ambía\"" <leonfelipe at sanchez.mx<mailto:leonfelipe at sanchez.mx>>
Cc: "ccwg-accountability4 at icann.org<mailto:ccwg-accountability4 at icann.org>" <ccwg-accountability4 at icann.org<mailto:ccwg-accountability4 at icann.org>>
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.