[CCWG-ACCT] A contractual solution for the "membership"/accountability problem

Mailing List for the ICANN Accountability & Governance Cross Community Group accountability-cross-community at icann.org
Tue Oct 13 22:17:50 UTC 2015


Yes I read it. It does say that the line is 
unclear, but that certain responsibilities cannot 
be delegated including budget and strategic. 
Plan. Our lawyers have been clear for a long time 
that budget and plan veto are problematic in a 
non-member situation. And that matches the 
Board's position that to give this up impacts 
their fiduciary duty (and I agree).

The ALAC has said it would reluctantly accept the 
member model, but it is not our preference, and 
that implies we are willing to forego the budget/plan veto.

Alan

At 13/10/2015 05:45 PM, Aikman-Scalese, Anne wrote:
>Alan, did you read the Sidley memo Mathieu 
>circulated that says the in the current 
>corporate structure, the ICANN Board cannot 
>delegate decision-making in relation to the 
>corporation to any third party, including via 
>binding arbitration?  This is on page 2 of the 
>Appendix.  Wouldn't that also impact a contract 
>theory where decision-making in relation to 
>budget/plan veto is delegated via contract to 
>the party on the other side of the contract?
>Anne
>
>Anne E. Aikman-Scalese
>Of Counsel
>Lewis Roca Rothgerber LLP |
>One South Church Avenue Suite 700
>Tucson, Arizona 85701-1611
>(T) 520.629.4428 | (F) 520.879.4725
>AAikman at lrrlaw.com | www.LRRLaw.com
>-----Original Message-----
>From: 
>accountability-cross-community-bounces at icann.org 
>[mailto:accountability-cross-community-bounces at icann.org] 
>On Behalf Of Alan Greenberg
>Sent: Tuesday, October 13, 2015 1:36 PM
>To: David Post; Accountability Cross Community
>Subject: Re: [CCWG-ACCT] A contractual solution 
>for the "membership"/accountability problem
>
>With the usual "I am not a lawyer disclosure", 
>my understanding is that the Bylaws are 
>effectively a contract. In all of the contructs 
>(whether it is the CMSM, CMSD or (my most recent 
>proposal) CMSanything, there is an UA composed 
>of the AC/SO (or a subset), or in the earlier 
>models multiple UA, one per AC/SO. In the Board 
>proposal, since I do not believe that the AC/SO 
>Chairs are willing to assume responsibility for 
>taking actions personally (nor should they be 
>expected to), there would also have to be an UA 
>formed to act on behalf of the AC/SOs. As I 
>understand it, the UA would have to exist at the 
>time the of the violation or act that it was 
>complaining about, so that really implies it 
>would have to exist at the start (since one 
>cannot predict when trouble will arise.
>
>So in my mind, the CMSx, the Board proposal, and 
>your new one all really have a common construct 
>of a UA acting on behalf of the AC/SOs. The 
>differences are in how the "contract" or the Bylaws allow the UA to act.
>
>The recent legal briefing on our current model 
>(ie in the Bylaws today) says that although the 
>AC/SOs and NomCom that appoint board members are 
>not called designators, for all intents, they 
>are. The new constructs (any of them) would 
>allow the AC/SOs or a subset to exercise the 
>powers other than appointment of directors. We 
>have been told (by CCWG lawyers) that these 
>powers are enforceable (other than budget/plan veto).
>
>  From a practical point of view, I think that 
> all of the proposals are in fact very close to 
> each other, but the different terminology and 
> in some cases, a lack of precision masks that similarity.
>
>Alan
>
>At 13/10/2015 04:08 PM, David Post wrote:
>
> >To all:
> >
> >David Johnson and I have been developing an idea that might be able to
> >break the impasse between the Board and the stakeholders regarding the
> >membership model as a vehicle for community control over the Board's
> >actions.  Here's David's description of the overall idea:
> >
> >ICANN Accountability ­ Back to Contract
> >
> >There is broad agreement that the community powers recommended by the
> >CCWG should be "enforceable"?. The proposal assumes that the
> >Unincorporated Association that would enforce them would have to be
> >created by, and made the sole "member"? of ICANN, by means of an
> >amendment to ICANN's bylaws. Only the Board can amend the bylaws, and
> >they do not want to create a member. This would appear to create an
> >unresolvable stalemate. Until one recalls the scene from Indiana Jones
> >when, treated by a knife twirling thug, the hero remembers that he has
> >a gun and uses it.
> >
> >As CCWG's counsel have noted, an unincorporated association can be
> >formed by any group with the requisite intent, with minimal formality.
> >So the community UA, consisting of and acting only at the direction of
> >the SOs and ACs that make up the ICANN community, could be formed
> >directly by the actions of that community. The UA, now a legal person,
> >could enter into contracts (using whatever decision-making process is
> >provided in the UA's own bylaws). It could, for example, make an offer
> >to enter into a contract with ICANN itself. Such a contract might
> >provide that ICANN would promise to adopt and abide by a specified set
> >of bylaws (notably, those providing for community powers and an
> >enhanced IRP). The contract could provide for specific performance and
> >dispute resolution (not unlike the MEM, but with the group doing the
> >"enforcing"? having been formed in advance of any bylaw violation). The
> >contract could make individual SOs and ACs, or even subcomponents of
> >these, into third party beneficiaries entitled to enforce the
> >contractual promises as against the ICANN corporation. In light of
> >these commitments, the community UA could itself then promise to give
> >its collective approval to the IANA transition.
> >
> >ICANN's Board would still need to agree to any such contract, to make
> >it binding. But the Board would no longer have an objection based on
> >supposed dangers of creating a "member"?. It has said it agrees that
> >the proposed community powers should be enforceable, and that IRP
> >decisions enforcing revised bylaws and mission statement should be
> >binding. The CCWG can reach its own consensus on what contractual terms
> >(what draft bylaws to include by reference and what community
> >decision-making process to use regarding decisions to offer and enforce
> >the contract). It would be difficult for the Board to refuse to sign
> >such a contract ­ once supported and offered by an Unincorporated
> >Association consisting of the community and 
> acting with requisite consensus).
> >
> >The community only supported "membership"?
> >because this was thought to be the only way to make the proposed
> >community powers enforceable against a reluctant ICANN board. If there
> >is another way to accomplish enforceability, while avoiding the Board's
> >objections to "structural change"? of ICANN itself, that should be
> >acceptable. That "other way" is to enter into a contract under which
> >ICANN promises to adopt and comply with specified bylaws and to
> >establish a binding IRP.
> >Because there won't be a binding IRP to enforce a duty to create a
> >binding IRP, the registry constituency has already suggested that there
> >be a contract that requires ICANN to follow through on that promise.
> >This suggestion just applies the same principle to the entire community
> >and all of the proposed community powers. It's time for ccwg to start
> >drafting contract terms.
> >
> >
> >***********************************************
> >
> >Here's a rough outline of the logistics of how this would work:
> >
> >Acting by consensus resolution, SOs and ACs would form an
> >unincorporated association. This would include writing bylaws regarding
> >decision-making process for the UA (action solely at direction of
> >consensus of SOs/ACs?) As its first act, the UA would offer ICANN a
> >contract with the following terms.
> >
> >1. ICANN would agree to adopt and abide by a specified set of bylaws
> >(which would be attached as an exhibit to the contract) that set forth
> >community powers and establishment of binding IRP.
> >
> >2. The contract would have a term coterminous with ICANN's existence
> >and could not be cancelled. (no expiration date and no grounds for
> >termination by ICANN)
> >
> >3. The contract would call for specific performance.
> >
> >4. Disputes would be resolved by the IRP, and would be binding on ICANN
> >(even if ICANN chose not to appear before the panel).
> >
> >5. In addition to the UA itself, Any two SOs or ACs, acting by internal
> >consensus, could bring a case to enforce the provisions, and ICANN
> >would pay the costs of such a case.
> >
> >6. The contract would name as third party beneficiaries any Individual
> >SO/AC, sub constituencies and any parties materially harmed by breach
> >of the agreement - providing that these third parties could also bring
> >a case to enforce the agreement, at their own expense, with costs
> >allocated by the IRP).
> >
> >7. ICANN would promise that, in the event the terms of the contract
> >could not be enforced in the absence of a "membership" structure, it
> >would recognize the UA as a member under California law.
> >
> >8. ICANN would warrant that it has the authority to enter into the
> >agreement and agree that it will not assert in the future that
> >compliance with the contract would be prevented by any claimed conflict
> >between the contract and the ability of the Board to exercise its
> >fiduciary duties.
> >
> >9. The UA would agree, in light of these ICANN promises, to support the
> >transition (treating ICANN as the steward of the IANA function and as
> >the source of policy for dns absent any ability of US Government to
> >take that role away).
> >
> >Obviously, there are still some unresolved details regarding what the
> >bylaws would say (e.g., re community oversight of budget). These would
> >have to be resolved.
> >
> >
> >David
> >*******************************
> >David G Post - Senior Fellow, Open Technology Institute/New America
> >Foundation blog (Volokh Conspiracy)
> >http://www.washingtonpost.com/people/david-post
> >book (Jefferson's Moose)  http://tinyurl.com/c327w2n music
> >http://tinyurl.com/davidpostmusic  publications etc.
> >http://www.davidpost.com
> >*******************************
> >
> >*******************************
> >David G Post - Senior Fellow, Open Technology Institute/New America
> >Foundation blog (Volokh Conspiracy)
> >http://www.washingtonpost.com/people/david-post
> >book (Jefferson's Moose)  http://tinyurl.com/c327w2n music
> >http://tinyurl.com/davidpostmusic  publications etc.
> >http://www.davidpost.com
> >*******************************
> >_______________________________________________
> >Accountability-Cross-Community mailing list
> >Accountability-Cross-Community at icann.org
> >https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>_______________________________________________
>Accountability-Cross-Community mailing list 
>Accountability-Cross-Community at icann.org
>https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
>________________________________
>
>This message and any attachments are intended 
>only for the use of the individual or entity to 
>which they are addressed. If the reader of this 
>message or an attachment is not the intended 
>recipient or the employee or agent responsible 
>for delivering the message or attachment to the 
>intended recipient you are hereby notified that 
>any dissemination, distribution or copying of 
>this message or any attachment is strictly 
>prohibited. If you have received this 
>communication in error, please notify us 
>immediately by replying to the sender. The 
>information transmitted in this message and any 
>attachments may be privileged, is intended only 
>for the personal and confidential use of the 
>intended recipients, and is covered by the 
>Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.




More information about the Accountability-Cross-Community mailing list