<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Dear Eric, Dear Colleagues,<br>
<br>
I think as a first phase we should try and expand our list of
candidates contingencies before focusing to higher impact / most
relevant ones. The BC ones may need some adjustment to be considered
"contingencies" but I think they are a relevant contribution.
Malcolm Hutty's scenarios are useful as well.<br>
<br>
As discussed during the call today, I'd like to offer additional
possibilities where we could find contingency ideas. First of all,
while reading the latest SSAC advisory (SAC069) I noticed the
following recommendation : <br>
<blockquote type="cite">
<blockquote>Recommendation 3: Each of the communities should
investigate and clarify the process<br>
for handling the possibility of governmental sanctions and
restrictions (e.g., the protocol<br>
for obtaining OFAC2 licenses where U.S. sanctions might
interfere with the ability to<br>
execute proper instructions to IANA) following the stewardship
transition.<br>
</blockquote>
<br>
</blockquote>
We could turn that into the following contingency : "New regulation
passed prevents Icann from servicing some parts of the community,
for example for specific countries or regions of the worlds". <br>
<br>
More generally, inspiration for contingencies can be found in
generic risk management standards. All of them start with
identifying a list of threats that are relevant to the organisation.
Unfortunately my documentation on the matter is all in French and
I'm struggling to find references in English but to illustrate the
kind of threats that are usually explored I can provide the
following non exhaustive list :<br>
- Anti-Trust action (or class action) against Icann<br>
- New regulation or legislation (see above)<br>
- domain industry financial crisis, leading to sudden drop in
revenues for Icann<br>
- conflict with a significant financial contributor leading to this
stakeholder refusing to pay fees<br>
- new technology competing with DNS leading to sudden drop in domain
name numbers<br>
- Governance crisis within Icann leading to inability to reach
decisions for a long period of time (6 months to 18 months)<br>
- Major corruption or fraud within Icann<br>
- Chairman, CEO or major officer acting in a manner inconsistent
with the organisation's mission<br>
- Major personal data leak due to failure of Icann's security<br>
- Financial crisis affecting Icannn's reserves in a manner that
threatens its continuity<br>
<br>
I hope this helps, please feel free to elaborate or reject. <br>
<br>
Best,<br>
Mathieu<br>
<br>
Le 16/12/2014 04:05, Eric Brunner-Williams a écrit :<br>
<blockquote cite="mid:548FA175.4020406@abenaki.wabanaki.net"
type="cite">Dear Colleagues,
<br>
<br>
During the December 9th CCWG-Accountability conference call Steve
DelBianco (BC) mentioned a document prepared by the Business
Constituency entitled "Stress Tests". The URL for this document is
at [1] below. In this note I'll discuss the BC's ten suggested
scenarios, and I urge you all to read through the original
document.
<br>
<br>
--
<br>
BC #1. Cancellation of the AoC.
<br>
<br>
I am not a lawyer, but my wife is, and restating the hypothetical
as "what constrains the conduct of the successor contractor in the
absence of the existing contractual conditions" seems to avoid the
question of accountability altogether.
<br>
<br>
I suggest this item be deferred until clarified.
<br>
<br>
--
<br>
BC #2. Flight to avoid jurisdiction.
<br>
<br>
I am not a lawyer, but my wife is, and restating the hypothetical
as "in what jurisdictions would Verisign, GoDaddy, ... be unable
to determine likely contested issue outcomes" yields a very
unlikely set of possible answers.
<br>
<br>
I suggest this item should be discarded as a distraction.
<br>
<br>
--
<br>
BC #3. Insolvency.
<br>
<br>
The is a business continuity question, for which a number of
equivalent, and more likely, scenarios exist.
<br>
<br>
I think this item can be improved by asking what Continuity issues
are reflected in the Corporation's plan of record, and whether
distinct accountability issues exist.
<br>
<br>
--
<br>
BC #4. Applicant Support Revisited.
<br>
<br>
The ICANN BoC indicated at the Nairobi meeting that "diversity"
necessitated activity -- realized in that period by the (Cross
Community) Applicant Support Working Group (ASG), which inter
alia, included the possibility that the support provided to some
applicants could come directly from ICANN, in the form of reduced
regulatory burdens, reduced application fees, reduced recurring
costs, etc. Recommendations by the ASWG to this effect were
opposed during the public comments periods by the BC, hence my
summary that this revisits the BC's position of record on the ASWG
sets of recommendations.
<br>
<br>
I suggest that this item can be improved by asking what happens if
ICANN attempts to regulate some activity which is outside of the
usual three buckets of names, protocol parameters, and addresses,
and without implicitly privileging early adopters. Then a
meaningful accountability question can be posed and a credible
scenario constructed.
<br>
<br>
--
<br>
BC #5. Ignoring SSAC
<br>
<br>
The accountability issue here isn't obvious to me. The bylaws
create several Advisory Councils, and when they function they can
provide the Board with advice opposed to some decision the AC
anticipates the Board may make. No accountability necessarily
arises when the Board (frequently) does not follow the advice
offered by an AC. The BC comments refer to "new accountability
mechanisms" in the context of gTLD delegation.
<br>
<br>
I suggest that this item can be improved by asking what
accountability issues exist with respect to new gTLD
(re)delegeation. See also BC #7 and BC #8, infra.
<br>
<br>
--
<br>
BC #6. GAC votes
<br>
<br>
The accountability issue here isn't obvious to me. The bylaws
create several Advisory Councils, each of which may have distinct
internal processes resulting in the issuance of advice. A change
in any AC's internal process does not necessarily create an
accountability issue.
<br>
<br>
I suggest this item should be discarded.
<br>
<br>
--
<br>
BC #7. .xxx redux
<br>
<br>
This appears to revisit the .xxx issue, within the hypothetical
framework of BC #6 -- a GAC vote rather than a lack of GAC
consensus and overt (and covert) expressions of displeasure by
Governments.
<br>
<br>
As this is an instance of #6, I suggest this item should be
discarded as with BC #6.
<br>
<br>
--
<br>
BC #8. Contested gTLD Regelegation
<br>
<br>
This revisits BC #2, supra, the hypothetical case assumes some
novel jurisdiction in which Verisign and others which maintain and
publish the IANA root zone. As this is an instance of #2, I
suggest this item should be discarded as with BC #2.
<br>
<br>
--
<br>
BC #9. Enjoined Delegation
<br>
<br>
This revisits BC #2, supra, the hypothetical case assumes some
novel jurisdiction in which "ICANN and the IANA" are "empowered"
to litigate a registry contract.
<br>
<br>
As this is an instance of #2, I suggest this item should be
discarded as with BC #2.
<br>
<br>
--
<br>
BC #10. Contested ccTLF Redelegation
<br>
<br>
The policy for ccTLD redelegation has been, with the exception of
.iq, where the incumbent delegee was in the custody of the United
States, agreement by all parties. Until this policy is formally
changed this does not appear to exercise an accountability issue
beyond the existing practice of accounting for ccTLD change
requests.
<br>
<br>
I suggest this item should be discarded.
<br>
<br>
----
<br>
<br>
After several readings of the BC's document I'm unable to discern
significant likely scenarios for which accountability issues
exist. It is quite possible that I'm reading this with
insufficient information, or unfairly due to long familiarity with
the BC's positions of record on diversity and access, or unfairly
due to a personal impression that several of the "scenarios" are
quite unlikely, or ambiguous to the point of non-meaning, or both.
<br>
<br>
To its credit, the BC has attempted to find scenarios of general
utility, and offers these suggestions, so that "we [c]ould
consider ... scenarios that could arise."
<br>
<br>
Any colleague who arrives at a different reading I hope will
articulate his or her reading on any or all of BC #1 through BC
#10, as mine is only one view of a document offered for collegial
review.
<br>
<br>
Eric Brunner-Williams
<br>
Eugene, Oregon
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://www.bizconst.org/StressTests/">http://www.bizconst.org/StressTests/</a>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
*****************************
Mathieu WEILL
AFNIC - directeur général
Tél: +33 1 39 30 83 06
<a class="moz-txt-link-abbreviated" href="mailto:mathieu.weill@afnic.fr">mathieu.weill@afnic.fr</a>
Twitter : @mathieuweill
*****************************
</pre>
</body>
</html>