[CCWG-ACCT] Blog: Working Together Through The Last Mile

[Malcolm Hutty]

Wolfgang,

Thank you for your detailed message.

I shall address it point by point. I apologise in advance for the length
of this reply.

On 07/09/2015 09:22, "Kleinwächter, Wolfgang" wrote:
> What are the facts? For nearly all CCWG building blocks we have an agreement:
> •	Community empowerment (Agreeement)
> •	Removal of the Board (Agreement with some minor specifications)
> •	Fundamental Bylaws (Agreement)
> •	Operational Plan (Agreement)
> •	Budget (Agreement with some minor clarifictions)
> •	Enforceability (Agreement)
> •	IRP (Agreement)
> •	Ombudsman (Agreement) 

I don't think we do have agreement on all those points.
As a particular example, we made specific proposals for how the IRP
change. On the Board call we were told that the Board proposes that
instead of implementing those proposals

    "because we understand that the community is not happy with the
     current situation we would suggest that we roll back the
     modification of the standard of review to where it was before
     2013, and that there is a commitment that the revised standard
     of review standing panel and procedural improvements will be part
     of the next phase of work on the IRP enhancements."

Reverting to 2013 rules and the promising to come back and look at it
later, after transition is not at all what we proposed. So I don't think
we do have agreement yet.

You say you also support enforceability, which is enormously heartening.
But the things the Board has proposed would not deliver that.


Perhaps when we use the word "enforceability" we simply mean different
things?

When I talk about a decision that is enforceable against ICANN, I mean
one which ICANN has to comply with. In the final analysis, that would
mean the ability to go to court and get an order. In the *final* final
analysis, breaking a court order does result in real actual force being
applied against you, by officers acting on behalf of the court.
Obviously, it would never come to that: ICANN would comply with a court
order. For the same reason, we don't imagine that it would ever come to
needing to seek a court order to force ICANN to comply with an IRP
judgement: the fact that one would be available would mean ICANN would
have no choice but to comply. That is what we are seeking to establish,
for the class of decisions we have said we wish to be enforceable.

That class of decisions is very small. The most used one, in my
expectation, is the IRP. That must be available (i.e. ICANN can't say,
"we don't think the IRP should apply to this case") and ICANN must abide
by the outcome. If ICANN sought to avoid the IRP, well that's when the
enforcement aspect (as I have defined it above) comes in. And provided
we can enforce, ICANN will have to comply: and so ICANN will in practice
comply from the outset, and we won't need to go to court at all, any
more than the court needs to send the bailiffs round to your HQ.

Similarly, the CCWG proposes that the Community should be able to
dismiss an individual director, or all of them, to veto a change to the
bylaws, and that any change to a specific subset of bylaws we designate
as "fundamental" will only take effect when the Community has positively
approved it. Finally, the CCWG also proposes that Community should be
able to prevent a new budget or a new strategic plan going into effect.

These are the powers that the CCWG wants to create, and it wants them
all to be enforceable in the sense I have described. True, not every
single participant in the CCWG considers enforceability an absolute,
vital requirement, but many do. We are clear on two things: (i) we have
managed to achieve a broad consensus within CCWG in support of the
proposal we have put forward, pace the dissents that have been
published; and (ii) the quest for enforceability is held sufficiently
dear by a sufficient broad range of stakeholders that there is no
prospect of getting anything like this level of consensus for an
alternative proposal that does not offer enforceability. Moreover, the
names community's CWG transition proposal is expressly contingent upon
success here, so a failure to achieve a credible consensus here also
wrecks the ICG transition proposal.


Let us set aside for the moment the question of the mechanism by which
the Community exercises those powers. The principle of enforceability
says that in the final analysis it is the IRP Panel's view, not the
Board that must prevail in an IRP case; and the Community's view, not
the Board's view, that must prevail when those powers are exercised.

Do you really agree that enforceability must be the operative principle
in this sense?


If you do agree, then we can turn to the question of the model that is
used to deliver it. And (having agreed it) we will dismiss from
consideration any models that do not offer it.

If you do not agree with this fundamental objective, then there is no
point in discussing the model: we must resolve this point first.

I think some of my colleagues suspect the Board of pretending to an
agreement that they do not really hold in the hope of slipping past us
proposals that deliver according to a different set of principles. I
would not accuse you of that personally Wolfgang, it's not your style,
but allow me to address this possibility to "you" in the abstract. I
would warn that such a tactic is unwise. There is little prospect that
this CCWG, which has examined these issues so closely and at such
enormous length, can be misled in such a fashion. If the Board were to
attempt it, all it would achieve would be to damage trust further. It
might also waste some more of our time while we uncover the reasons why
the Board is proposing a model that fails to deliver on their purported
objectives; but, frankly, we are now so familiar with this issue that we
can see that coming a mile off.

But let me hope that you have read this far and are reasonably content
that we are in accord about the meaning of we each ascribe to to term
"enforceable accountability", and that we share it as a goal. If we are,
then we are in the happy state of agreement about objectives, and are
genuinely able to collaborate on the best way to achieve them.


About our "Sole Member Model" you said:

> 
> The reason why I have problems with the sole membership model is
> simple: I am in favor of a new mechanism to strengthen the checks and
> balances in the ICANN system to keep the board (and the other ICANN
> bodies) accountable to the community. But in my eyes the proposed
> Sole Membership Model  is untested, has a number of risks and is open
> for unintended side-effects. I am not convinced that the proposed
> voting mechanism is save enough against capture. I did not get a
> satisfying rationale why Advisory Committees are treated so
> differently in the proposed mechanism. I have my doubts how
> governments can be included in an appropriate way into this new
> mechanism without touching the well designed balance between
> governments and the non-governmental stakeholders in the ICANN
> ecosystem.  And there are other detailed questions.

If that is the limit of your problems with the Sole Membership Model,
there is scope for dialogue and collaborative working.

The Board's counter-proposal has led some people in this CCWG to suppose
that your problem with the Sole Member Model is not limited to those
concerns.

When the Board says "I don't like your Sole Membership Model", what many
have heard is that you don't like the entire *model* (and have presumed
from that, not without justification, that the aspect the Board dislikes
is enforceability). By contrast, I think the points you raise above only
address the specifics of how that model is implemented.

Let's unpack the term, and consider both "Sole" and "Membership" separately.

CCWG considered models that did not have "Membership" at their core.
Many of us initially would have preferred to find a model without
membership, but on close examination (and with the benefit of legal
advice) we discovered that *only* a membership model can deliver
enforceability.

This wasn't a limitation of our creation. Enforceability as I have
described it requires at least the theoretical possibility of going to
court and saying "The governing documents require this outcome, but the
Board is refusing to abide by them. Please order it to do so." Even
though we expect that this will never be required, that expectation
rests entirely on the invocation of the power of the court being *possible*.

We were told by counsel that, setting aside contractual disputes, only
two classes of person have the ability to go to court in this fashion.
Those two classes of person are:
i) a director of the corporation; and
ii) a member of the corporation.

Nobody else*. As a matter of law.

   [*Actually, there is also the Attorney-General for California,
    but nobody wanted to rely on that as an accountability mechanism;
    we are looking for accountability mechanisms rooted in the
    multistakeholder community, not transferring primary oversight
    responsibility from the Federal to the State level]

So if there are no members then nobody can go to court to bind ICANN to
its own governing documents, and enforceability of them is unachievable
as a matter of law.

This is the reason that the "Sole Designator Model" mentioned by Jones
Day must be discarded: lacking a member, it lacks the legal possibility
of enforceability. Whatever other merits it may have are, sadly,
irrelevant: as a distinguished engineer, I know you fully understand
that excellent results in some areas cannot rescue a design that
critically fails to meet one of the other core requirements.

That narrows our search space to membership models.

To hammer this point home, any model that does not involve a member of
some description is unacceptable, not because we are especially attached
to the idea of a membership model, but because we are adamant that we
need enforceability of the kind described above, and the legal advice is
that only some variety of membership model can deliver it.

CCWG looked at several varieties of membership models. Our first draft
proposal was to turn SOACs into the Members of ICANN. We also considered
having SOACs appoint people to become members of ICANN. A brief mention
was also given to a model in which anybody could become a member of
ICANN; this was swiftly discarded.
Following public comment, we revised our plan to a Sole Member Model,
where the "Member" of ICANN would simply be a legal concept, controlled
by the collective direction of the existing SOACs.

So that's how we got to our "Sole Member Model".

The criticisms you set out above are, with respect, not necessarily
criticisms of the Sole Member Model per se: that is, not necessarily
criticisms of the choice that our Model should have a Member at its
heart, nor of the choice that this member should be a theoretical
construct controlled by the SOACs, rather than something else.

They are instead criticisms of the rules that we propose for how the
SOACs control the Sole Member. Perhaps our voting thresholds are wrong.
Perhaps our processes for attempting to invoke the Sole Member's powers
are wrong. Perhaps the definition of who gets to vote, or the voting
weights between them need to be changed. And so forth.

If I may say so, if this is where the remaining disagreement between us
lies, then I am encouraged. These are implementation details: important
ones, certainly; difficult ones too. But we are not fighting against
each other in the same way we would be if you reject my definition of
enforceability.

Item one, however, must be to clear up whether you do indeed share the
same understanding. Many members of the CCWG have heard the Board
statement as meaning precisely that they seek to avoid enforcability
even while claiming to support it. That is not a basis for a productive
discussion, only for acrimony.

If however, you can now see why we have chosen a model in which there is
a Member, and in which there is only a single member, which is a
construct controlled by the SOACs, and if you can now support those
choices, then I urge you to say so even if you still have serious
misgivings about the particular way we have designed it. If you (and
your colleagues) are unable to go this far, then personally I fear that
by direct implication we may be about to lose consensus support for
transition.

> My first proposal was to dislink the discussion of the sole
> membership model from WS 1 and to have more time to go into the
> details of such a needed new mechanism in WS 2. This is obviously
> impossible. We have to propose something here and now within WS 1. I
> know that some CCWG members have mistrust into a long-term process
> and speculate that if they do not get it now they will get it never.
> I think this is wrong.  The process is unstoppable.

The process may be unstoppable, but is enforceability unstoppable?

Some people in CCWG have heard the Board's reply and interpreted it as
an attempt to stop it.

If you wish them to reconsider, I would advise the Board change tactics:
avoid making suggestions for alternative proposals that would plainly
not achieve enforceability of IRP decisions or Community powers.

> My impression is that the majority in the community sees this indeed
> as an ongoing process of ICANNs improvement which will not stop with
> the IANA transition. 

I think we are all agreed on this.

> and what is needed under WS 1 to allow the termination of the IANA
> contract. But this will not be the end of the story. It will go on.

Indeed. And CCWG carefully defined WS1 as only those things that it
considers an essential pre-condition for termination and transition.

> And here is a final observation.  To put it – like Greg – as a
> conflict as “Board on Top” vs. “Community on Top” is misleading. Both
> the members of the Board and the members of the CCWG are selected by
> the community. Both are accountable to the community.

I respectfully disagree. In many important respects the Board is wholly
unaccountable. That is not intended as a personal slight; it is an
assessment of the current structure.

For example, last year the Board proposed changing the Bylaws as to how
GAC advice is treated. There was a major outcry, and the Board listened
to the community and decided not to implement that change (at least, not
at that time, or since). I applauded that, and thanked you in the Public
Forum.

But what if you had pressed ahead anyway? What could anybody who is not
a Board member have done about it? Well, we could have filed a
Reconsideration Request: I believe at least one was filed pre-emptively.
But that process would not, could not, force you to reverse that
decision if you insisted upon it.

All we can hope is that the Board chooses to listen. It usually does,
and we thank you for that, but that is the very definition of lack of
accountability. That is the current inadequacy we are trying to fix.

The CCWG's proposal is very modest. It does not seek to create a means
whereby we might routinely impose the community's preferences over those
of the Board, or be able reverse the Board at will. It asks for two things:

i) that an independent arbitrator will always be available to hold the
Board to account specifically for failure to abide by ICANN's own
governing documents, and will be able to compel compliance; and

ii) that the Community will have the last word in a very narrowly
specified set of decisions (removal of directors, changes to bylaws, and
approval of a new budget and strategic plan), and would do so only
provided the Community first meets an incredibly high threshold for
consensus.

That is a modest and reasonable request, and the minimum necessary so
that we will be able to say that the NTIA has transferred the oversight
of ICANN to the global multistakeholder community.

Kind Regards,

Malcolm.
-- 
            Malcolm Hutty | tel: +44 20 7645 3523
   Head of Public Affairs | Read the LINX Public Affairs blog
 London Internet Exchange | http://publicaffairs.linx.net/

                 London Internet Exchange Ltd
           21-27 St Thomas Street, London SE1 9RY

         Company Registered in England No. 3137929
       Trinity Court, Trinity Street, Peterborough PE1 1DA