[CCWG-ACCT] Recommendation 11, 2/3 board threshold, GAC consensus, and finishing

Phil Corwin psc at vlaw-dc.com
Thu Jan 28 23:48:00 UTC 2016

Well stated

Philip S. Corwin, Founding Principal
Virtualaw LLC
1155 F Street, NW
Suite 1050
Washington, DC 20004

Twitter: @VlawDC

"Luck is the residue of design" -- Branch Rickey

From: accountability-cross-community-bounces at icann.org [mailto:accountability-cross-community-bounces at icann.org] On Behalf Of Jordan Carter
Sent: Thursday, January 28, 2016 5:44 PM
To: Andrew Sullivan
Cc: Accountability Cross Community
Subject: Re: [CCWG-ACCT] Recommendation 11, 2/3 board threshold, GAC consensus, and finishing

Dear Andrew, all:

I see the situation a little bit differently.

It seems to me there is fairly broad agreement about these points:

- the GAC's advice is advice, and does not bind the ICANN Board
- the Bylaws set out how the Board should deal with GAC advice (attempt to come to an agreement - wrong language but you get the point)
- GAC today generates advice by consensus
- GAC today could change the way it generates advice
- the ICANN Bylaws should clearly state that the way the Board has to respond to GAC advice should only apply to consensus GAC advice
- the Board has the ability to not accept GAC advice even if it works through the "attempt to come to an agreement" process.

The critical difference we were discussing with our two options today is whether, in deciding not to accept GAC advice, the Board can

(point 5) make that decision by majority, or
(point 6) whether it has to achieve 2/3 support to make that decision.

We know that in practice the ICANN Board would generally made a decision like this *by consensus*, so there is very unlikely to be any practical difference whichever option we choose.

We also know that when the ICANN community was consulted about the idea of raising the threshold in the bylaws to 2/3, it was overwhelmingly rejected.

May I add two other points I think that we know, but which are probably controversial:

- the GNSO is unlikely to be able to approve the proposal with the 2/3 rule in place
- the GAC is unlikely to be able to come to a consensus to reject the proposal in the absence of the 2/3 rule.

I've explained why I think there is no practical difference between the two alternatives. Either way the Board will operate by consensus if at all possible on such weighty matters.

That said, I do recognise the importance of the symbolism here. So let me set out my view of this.

I think that governments form an integral part of the ICANN community. In a context of private sector led multistakeholder governance of the Internet DNS, they have to be at the table in an appropriate way.

That's why I support GAC as an advisory body only in dealing with ICANN's main business - its various policy development processes.  It is also why I support it as a decisional participant in the exercise of the limited and narrow set of accountability powers our proposals deal with.

There is certainly no disrespect of sovereign states or the role of governments on my part when I say that the symbolism of 1/2 v 2/3 is simply not a battle worth fighting, especially when the rest of the ICANN community has so clearly expressed its view - and when it is so clear that it will make no practical difference whatsoever.

I'll close by appealing again to what we are trying to do here. We are trying to close out a proposal, sure - and that should lead to all the chartering organisations supporting it, or at least not opposing it. I see that happening most simply through the Point 6 proposal - simple majority rule for the Board.

But besides closing out this proposal, we are all trying to build a stable and constructive post-transition ICANN. Acknowledging and respecting our respective roles and responsibilities in that is important. In my view the CCWG will likely decide to proceed with Point 6. If that is right, it is a responsibility of all of us to portray that for what it is: a decision made on logical grounds, taking the feedback of the ICANN community into account. It is not an insult, or a symbolic "win" or "loss" for anyone.

I appeal to everyone who's got a deeply entrenched position on this argument either way to make sure that the discussion and decisions over the next few days are done with that spirit of coming to a sound conclusion, and that whichever way it goes, the good faith of all participants isn't in doubt.  That's the best thing I can think of to help us get this work done in a durable and successful way.


On 29 January 2016 at 09:57, Andrew Sullivan <ajs at anvilwalrusden.com<mailto:ajs at anvilwalrusden.com>> wrote:
Dear colleagues,

I was going to make a comment on the call today, but in the interests
of time I took myself out of the queue.  This note replaces what I
wanted to say.

For those chartering organizations and individuals that wish to reject
the compromise, I have a question.  If the proposed compromise
position on recommendation 11 is rejected, there is a good reason to
suppose that at least one important part of the community (the GAC)
will reject the accountability proposal.  That will conceivably
scuttle the transition; and in the absence of a consensus on the
accountability measures, there is no reason to suppose we'll get the
additional powers that are in the current text (incuding the Empowered
Community).  Is it worth it to give up those additional powers to
prevent the 2/3 board threshold, given that the additional powers
provide a way to foil truly bad decisions anyway?

As I understand things, we are in a trap.  On the one hand, the GAC
has produced a consensus position that the board must reject GAC
advice by a supermajority.  And indeed, as things are, the ICANN board
has a difficult time even under the current arrangements when it
decides to reject GAC advice.  Yet the GAC is currently free to
rearrange its own procedures such that it could lower its own
threshold for decisions.  Therefore, the consensus position of the GAC
represents a grave threat to the transition.  The current state of
affairs is in any case not that hot; and the GAC could unilaterally
make that current state of affairs worse.

The compromise proposal does a few things.  It is true that it
increases the threshold for the board to reject GAC advice.  But in
exchange for that, it enshrines the GAC's responsibility to the rest
of the ICANN community as to how the GAC will reach decisions.  This
means that, in exchange for the increased threshold -- a threshold
that I think will be easy to reach regardless of the actual numbers on
the board in any case that counts -- the GAC is giving up independent
control over its decision-making procedures when exercising that
threshold.  In that way, it is actually an improvement of GAC's
covenant with the ICANN community.

Moreover, let us suppose that the GAC produced advice that the board
decided to accept, but the rest of the community found that
objectionable.  In that case, the rest of the community could force
the board not to take the advice _anyway_, because of the additional
accountability measures that this CCWG wants to put in place.

The compromise proposal is not perfect -- I too would prefer not to
have the 2/3 rule -- but one does not expect complete satisfaction
from a compromise.  And it should be surprising to no-one that it came
rather late: each side wants something pretty big, and both appear to
be dug in.  This means that each will need to give something up.
That's what deals look like.  And we need a deal, and soon, because we
need to move ahead with the IANA transition.

Best regards,


Andrew Sullivan
ajs at anvilwalrusden.com<mailto:ajs at anvilwalrusden.com>
Accountability-Cross-Community mailing list
Accountability-Cross-Community at icann.org<mailto:Accountability-Cross-Community at icann.org>

Jordan Carter

Chief Executive

+64-4-495-2118 (office) | +64-21-442-649 (mob)
Email: jordan at internetnz.net.nz<mailto:jordan at internetnz.net.nz>
Skype: jordancarter
Web: www.internetnz.nz<http://www.internetnz.nz>

A better world through a better Internet

No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2016.0.7227 / Virus Database: 4489/11316 - Release Date: 01/03/16
Internal Virus Database is out of date.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160128/6aff76cf/attachment-0001.html>

More information about the Accountability-Cross-Community mailing list