[CCWG-ACCT] Recommendation 11, 2/3 board threshold, GAC consensus, and finishing
psc at vlaw-dc.com
Fri Jan 29 00:35:16 UTC 2016
Some further thoughts:
It is disappointing that the GAC’s comments on the Third Draft Proposal did not take a position on Recommendation 11, or even provide useful details regarding the reason(s) why some GAC members supported or opposed it. That shortfall places the rest of the community in the position of having to speculate on the reasons as we attempt to resolve a matter centering on the GAC’s role in a post-transition ICANN.
However, that shortfall on a matter in which the GAC has a very large stake reinforces my own experience with the GAC since I have engaged on ICANN matters -- which is that the GAC has difficulty reaching consensus, and that when it does it talks a considerable amount of time to get there. That’s perfectly understandable as the GAC is composed of representatives of sovereign nation states with widely divergent perspectives, and that GAC members cannot take a position until it is approved by the government officials they report to.
In short, the GAC tends to lag considerably behind the rest of the ICANN community in the timing of providing its official view – and in many instances is unable to reach consensus as presently defined. The only way to shorten that timeline would be for the GAC to change its definition of consensus to a lower threshold of agreement – or even begin operating by majority vote—and it seems evident that the large majority of the community would not wish for such a development.
Once it is finally rendered, the Board’s acceptance or rejection of GAC advice depends on less the difference between a majority versus two-thirds voting threshold than the selection of Board members who have allegiance to ICANN’s Mission, Commitments and Core Values, and to an Internet Governance narrative that welcomes governmental advice but rejects governmental control.
Given that a GAC operating under the definition of consensus memorialized in Recommendation 11 will almost always have a more difficult task in reaching consensus, and will take substantially longer to do so, than other Chartering organizations, my real concern is that including the GAC within the empowered community may substantially hinder the potential application of accountability measures in situations where time is of the essence. Therefore, while shaping the (hopefully final) Supplemental Proposal we need to make sure that the escalation process will be able to proceed at requisite speed even when one of the empowered entities is subject to the internal dynamics of the GAC and will often be unable to render a yay or nay.
Philip S. Corwin, Founding Principal
1155 F Street, NW
Washington, DC 20004
"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:
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.
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>
+64-4-495-2118 (office) | +64-21-442-649 (mob)
Email: jordan at internetnz.net.nz<mailto:jordan at internetnz.net.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...
More information about the Accountability-Cross-Community