Dear Colleagues, 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. -- BC #1. Cancellation of the AoC. 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. I suggest this item be deferred until clarified. -- BC #2. Flight to avoid jurisdiction. 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. I suggest this item should be discarded as a distraction. -- BC #3. Insolvency. The is a business continuity question, for which a number of equivalent, and more likely, scenarios exist. 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. -- BC #4. Applicant Support Revisited. 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. 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. -- BC #5. Ignoring SSAC 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. 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. -- BC #6. GAC votes 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. I suggest this item should be discarded. -- BC #7. .xxx redux 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. As this is an instance of #6, I suggest this item should be discarded as with BC #6. -- BC #8. Contested gTLD Regelegation 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. -- BC #9. Enjoined Delegation 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. As this is an instance of #2, I suggest this item should be discarded as with BC #2. -- BC #10. Contested ccTLF Redelegation 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. I suggest this item should be discarded. ---- 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. 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." 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. Eric Brunner-Williams Eugene, Oregon [1] http://www.bizconst.org/StressTests/