[CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board?

Mathieu Weill mathieu.weill at afnic.fr
Fri Dec 18 17:01:37 UTC 2015


Greg, All,



You are saying :

« It's my understanding (after looking into this) that the Board does not 
always take a formal vote when it "determines to take an action that is not 
consistent with" GAC advice. “



I must confess I do not understand how a Board in general, and Icann’s in 
particular, can act through anything other than a voting decision (even if 
it can be a consensus decision, it’s still a type of vote) ?



This makes this discussion very hard to follow for me.



Thanks for helping me out here.

Mathieu



De : accountability-cross-community-bounces at icann.org 
[mailto:accountability-cross-community-bounces at icann.org] De la part de Greg 
Shatan
Envoyé : vendredi 18 décembre 2015 17:30
À : Steve DelBianco
Cc : accountability-cross-community at icann.org
Objet : Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a 
new "mandatory voting requirement" for the ICANN Board?



Steve,



I know that's all that we (at least, you and I) wanted the addition of that 
one sentence to accomplish.  Initially, I was convinced that is all that was 
accomplished.  The more I think about this and discuss it, the less 
convinced I am.  Actually, I'm fairly we have accomplished, intentionally or 
not (or intentionally by some and not by others), quite a bit more than that 
by adding that sentence. (Actually we added a clause, not a sentence, and 
that distinction is important.)



Your walk-through includes one critical assumption about current Board 
practice that I don't believe is always supported by the facts.  You say 
"That decision is based on the board having a simple majority voting not to 
follow GAC advice. "  It's my understanding (after looking into this) that 
the Board does not always take a formal vote when it "determines to take an 
action that is not consistent with" GAC advice.  Please see my email to Alan 
Greenberg last night where I run through this in detail, so I don't make 
this email longer than it has to be.



In our haste and desire for finality, it is easy to assume that "determines 
to take an action" is the same as "voting" and that "an action that is not 
consistent with" GAC advice is the same as "rejecting" GAC advice.  These 
are bad assumptions (again see my email to Alan for more detail).



I know that the "draft Bylaws" are conceptual in nature (a point I've 
expressed myself many times), but words still matter.  Getting the concept 
right is what matters at this stage.  And I don't think we got it right --  
unless we intended to force the Board to vote every time it decides to take 
an action that is not consistent with GAC advice and we intended to frame 
that vote as a "rejection" (and we know how much everybody loves rejection). 
If that was our intention, we need to state it clearly and expressly and 
agree that is what we're doing.  If that was not our intention, we need to 
change the language of the draft bylaw.  We can't count on drafting notes. 
This will get too much attention as a series of new and/or higher hurdles to 
doing things any way other than the GAC way.



Finally, the reason it's important that this is a clause not a sentence: 
our new language is inserted as a predicate clause to the "mutually 
acceptable solution" process.  As a result, you can't get to that process 
unless you "reject" the GAC first. In other words, the Board loses the 
flexibility it currently has (and uses) to engage the GAC in that process 
without a formal Board vote.  This was not intended and must be corrected.



Greg







On Fri, Dec 18, 2015 at 10:28 AM, Steve DelBianco <sdelbianco at netchoice.org> 
wrote:

The current bylaws obligate ICANN to try and find a mutually acceptable 
solution if the board decides not to follow GAC advice. That decision is 
based on the board having a simple majority voting not to follow GAC advice. 
Today, the board almost always attempts to implement GAC advice and I’m not 
aware of instances where the board took a vote to either approve or reject 
GAC advice.



Our Recommendation #11 changed this one sentence in the bylaws regarding 
board obligations with respect to GAC advice.

Any Governmental Advisory Committee advice approved by a full Governmental 
Advisory Committee consensus, understood to mean the practice of adopting 
decisions by general agreement in the absence of any formal objection, may 
only be rejected by a vote of two-thirds of the Board, and tThe Governmental 
Advisory Committee and the ICANN Board will then try, in good faith and in a 
timely and efficient manner, to find a mutually acceptable solution.

Our Recommendation #11 does two things by changing that one sentence.



First, we narrow the board’s obligations only for GAC advice that was 
supported without a formal objection by any GAC member, which is how the GAC 
makes decisions now.



Second, we require our board to have 2/3 vote to reject that kind of GAC 
advice. 2/3 of 16 directors is 11 votes, whereas a majority is 9 votes.



If GAC advice came over with any formal objections by GAC members, the ICANN 
board could reject that advice with a simple majority, and would have no 
obligation to try and find a mutually acceptable solution if it did reject 
that GAC advice.





From: <accountability-cross-community-bounces at icann.org> on behalf of Keith 
Drazek <kdrazek at verisign.com>
Date: Friday, December 18, 2015 at 10:15 AM
To: Greg Shatan <gregshatanipc at gmail.com>
Cc: "accountability-cross-community at icann.org" 
<accountability-cross-community at icann.org>
Subject: Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a 
new "mandatory voting requirement" for the ICANN Board?



Greg raises very important points. Neither a "mandatory vote" nor a 
"presumption of acceptance" was intended. The only change proposed was to 
raise the threshold, under current practice, from simple majority to 2/3 if 
a vote was ever required at the last stage of the Board's consideration of 
GAC Advice. Nothing more. This should be made clear to the bylaw drafters.



Regards,

Keith


On Dec 18, 2015, at 12:53 AM, Greg Shatan <gregshatanipc at gmail.com> wrote:

Alan,



Nowhere does it say that there needs to be a "formal decision."  If the 
existing Bylaws required a vote, or even a "formal decision," before 
entering into the "mutually acceptable solution" process, the Bylaws would 
say so.  Instead, a more flexible term was chosen -- "determines to take an 
action."  Assuming competent lawyers, these language choices are meaningful 
and deliberate.  Elsewhere, the Bylaws clearly state when there are votes 
required (some variation of the word "vote" is used ~200 times in the ICANN 
Bylaws).  "Determines to take an action" is a unique phrase within the 
bylaws and virtually unique outside of it -- indeed, all but one Google 
result when searching on that term is a reference to this particular Bylaw. 
It's fairly clear to me that something less formal than a vote was intended 
by choosing this unique phrase.



It's my understanding that this distinction is carried out in the Board's 
actual practices, which have utilized the flexibility offered by this 
language. As presently drafted, the Board is able to identify a situation 
where it appears that they are going to take an action that would be 
inconsistent with GAC Advice; at that point, they would approach the GAC, 
tell them why and enter into the "mutually acceptable solution" process --  
without requiring a formal vote of the Board.  This gives the Board more 
flexibility and leeway to work with the GAC, and it's my understanding that 
the Board has in fact worked in this manner. The CCWG proposal would take 
away that flexibility and mandate a formal vote of the Board, requiring the 
Board to take an adversarial stance with the GAC.  [Choosng to use the 
flatly negative word "reject" instead of the more nuanced phrase "take an 
action that is not consistent with" is just the icing on the cake.]



There is another issue raised by this new language.  With this revision, it 
is far from clear what the status of GAC Advice that not been rejected by a 
2/3 vote?  If the Board takes a vote, but the rejection fails to pass, is 
the GAC Advice now "accepted" (possibly by a vote of 1/3+1) and binding on 
ICANN?  What about GAC Advice on which no vote has been taken -- is that 
Advice "accepted" and binding on ICANN and, if so, when?  [Compare this to 
the Community's right to reject a standard bylaws change -- if the community 
does not elect to do so, or attempts to do so and fails, that bylaw clearly 
become binding upon ICANN.]



The combination of a 2/3 threshold and a mandatory vote to reject GAC Advice 
creates a presumption that GAC advice will be accepted.  This presumption is 
novel and clearly elevates GAC Advice to a new level of deference within the 
ICANN process.



Although none of this is explicitly stated in the detailed explanation in 
Annex 11, the more I consider this and the more people I talk to, the more 
convinced I am that what I've laid out above is exactly what was intended by 
some of those involved in the drafting process for the Bylaw revision, and 
the rest of us just didn't see it at the time.  Since it's not brought out 
in the CCWG's explanation, this fundamental change can "fly under the radar" 
until the Proposal is approved.



I don't believe that this was the intention of the CCWG.  If it's not the 
intention of the CCWG, then my alternative wording would remove this 
concern.  If this is in fact the intention of the CCWG then I think it needs 
to be part of the explanation set forth in the proposal, so that the intent 
and effect are clear, and any reader can clearly understand what we have 
wrought.



Finally, I have to say that this is not an "implementation level" concern. 
This is, if you will, a "policy level" concern.  If this gets baked into the 
accepted proposal, then the implementers will essentially be bound to carry 
this out in the implementation (i.e., the drafting of the "real" Bylaw 
language).  Any later attempt to change a concept stated in the accepted and 
transmitted final proposal will face a very high set of hurdles, at best. 
Now is the time to deal with this.



Greg







On Thu, Dec 17, 2015 at 3:22 PM, Alan Greenberg <alan.greenberg at mcgill.ca> 
wrote:

Greg, you say that the current Bylaws do not reference voting. The current 
wording ( 
https://www.icann.org/resources/pages/governance/bylaws-en/#XI-2.1j 
<https://www.icann.org/resources/pages/governance/bylaws-en/#XI-2.1j> ) is 
"In the event that the ICANN Board determines to take an action that is not 
consistent with the Governmental Advisory Committee advice..."

How else is the Board able to formally decide on anything other than by 
voting?

Alan

At 16/12/2015 03:09 AM, Greg Shatan wrote:



All,

In reviewing the Third Draft Proposal, concerns have been raised within my 
constituency that the proposed Bylaw does more than replace an existing 
"majority" threshold with a new "2/3" threshold.  The concern is that the 
proposed Bylaw introduces a "mandatory vote" by the Board in order to reject 
GAC Advice where the Bylaws do not currently require a Board vote.  Further, 
there appears to be a concern that, if the Board does not take a vote and 
affirmatively reject a piece of GAC advice, then that GAC advice becomes 
binding on ICANN.

These concerns stem from a reading of the draft Bylaw (new language in red):



The advice of the Governmental Advisory Committee on public policy matters 
shall be duly taken into account, both in the formulation and adoption of 
policies. In the event that the ICANN Board determines to take an action 
that is not consistent with the Governmental Advisory Committee advice, it 
shall so inform the Committee and state the reasons why it decided not to 
follow that advice. Any Governmental Advisory Committee advice approved by a 
full Governmental Advisory Committee consensus, understood to mean the 
practice of adopting decisions by general agreement in the absence of any 
formal objection, may only be rejected by a vote of two-thirds of the Board, 
and tThe Governmental Advisory Committee and the ICANN Board will then try, 
in good faith and in a timely and efficient manner, to find a mutually 
acceptable solution.



​The current language of the Bylaw makes no reference to voting, only to 
the far more ambiguous "determines to take an action."  As such, adding a 
reference to a vote can be seen to add a new element (aside from the 
introduction of a 2/3 threshold): the element of a bylaws-mandated vote. 
Similarly, the statement that GAC Advice can only be rejected by a vote of 
the Board can be read to state that if no such vote is taken (or if such 
vote is taken and fails) that the GAC Advice is then something ICANN is 
bound to follow.

I don't think either of these things were intended by the CCWG.  Whether 
they are misreadings of our draft language or unintended consequences of the 
drafting, this concern is troubling.  If it is the intent of some of those 
drafting this language to force a vote where none is currently required, 
then that is even more troubling.

I would appreciate some clarification on these matters that I can bring back 
to my group.

I would also appreciate the CCWG considering a change in language to remove 
this ambiguity which is currently causing great consternation in my group.

I suggest the language below.  This m
ore closely track
​s​
the language of the existing bylaw and avoid the use of the term "vote," 
with its potential unintended consequences:

The advice of the Governmental Advisory Committee on public policy matters 
shall be duly taken into account, both in the formulation and adoption of 
policies. In the event that the ICANN Board determines to take an action 
that is not consistent with the Governmental Advisory Committee advice, it 
shall so inform the Committee and state the reasons why it decided not to 
follow that advice.

​

If the Board

​

determines to take an action that is not consistent with

Governmental Advisory Committee advice approved by a full Governmental 
Advisory Committee consensus, understood to mean the practice of adopting 
decisions by general agreement in the absence of any formal objection,

​

​such determination must be supported by

two-thirds of the Board, and the Governmental Advisory Committee and the 
ICANN Board will then try, in good faith and in a timely and efficient 
manner, to find a mutually acceptable solution.

​


I would appreciate your thoughts on this point and the revised language. 
Thank you.

Greg
_______________________________________________
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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151218/6b54baed/attachment-0001.html>


More information about the Accountability-Cross-Community mailing list