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
*******************************
|