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

Tue Oct 13 22:40:26 UTC 2015

Hi,

I understand that we also forgo separability if we do not have a member
model.

avri

On 13-Oct-15 18:17, Mailing List for the ICANN Accountability &
Governance Cross Community Group wrote:
> 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.
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus