<html>
<body>
We have th3e exact same situation with the Board accepting GNSO PDP
recommendations. It takes supermajority to reject. But we still say that
the GNSO "recommends" policy and it is adopted - or not - by
the Board. Saying that it takes a supermajority to reject is identical to
saying that acceptance only requires 1/3. There is no presumption. It is
simply a different threshold.<br><br>
Alan<br><br>
At 18/12/2015 01:11 PM, Robin Gross wrote:<br>
<blockquote type=cite class=cite cite="">Greg raises an interesting point
about the status of GAC advice in the absence of a 2/3 vote to reject it
below. I recall our lawyers telling us early on (and often) that
board members are not allowed to “off-load" key decisions of the
organization’s management to others as it would be a breach of their
fiduciary duty. But it seems like that is what we may have done
(intentionally or not) by presumptively accepting GAC advice and putting
the burden on the board to reject and undo the effect of that
decision. This may be an issue we need to further explore with our
lawyers.<br><br>
Robin<br><br>
<br>
<blockquote type=cite class=cite cite="">On Dec 17, 2015, at 9:51 PM,
Greg Shatan
<<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>
> wrote:<br><br>
[…]<br><br>
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.] <br><br>
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.<br><br>
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.<br><br>
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.<br><br>
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.<br><br>
Greg<br><br>
<br><br>
On Thu, Dec 17, 2015 at 3:22 PM, Alan Greenberg
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
> wrote:<br>
<dl>
<dd>Greg, you say that the current Bylaws do not reference voting. The
current wording (
<a href="https://www.icann.org/resources/pages/governance/bylaws-en/#XI-2.1j" eudora="autourl">
https://www.icann.org/resources/pages/governance/bylaws-en/#XI-2.1j</a>)
is "In the event that the ICANN Board determines to take an action
that is not consistent with the Governmental Advisory Committee
advice..."<br>
<br>
<dd>How else is the Board able to formally decide on anything other than
by voting? <br><br>
<dd>Alan<br><br>
<dd>At 16/12/2015 03:09 AM, Greg Shatan wrote:<br>
<blockquote type=cite class=cite cite="">
<dd>All,<br><br>
<dd>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.<br><br>
<dd>These concerns stem from a reading of the draft Bylaw (new language
in red):<br><br>
<dl>
<dl>
<dd>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.<br>
<br><br>
</dl>
</dl>
<dd><font face="verdana">â€â€¹The ccurrent 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.<br><br>
<dd>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.<br><br>
<dd>I would appreciate some clarification on these matters that I can
bring back to my group. <br><br>
<dd>I would also appreciate the CCWG considering a change in language to
remove this ambiguity which is currently causing great consternation in
my group.<br>
</font><br>
<dd>I suggest the language below. This m<br>
<dd>ore closely track<br>
<dd>â€â€¹sâ€â€¹<br>
<dd>the language of the existing bylaw and avoid the use of the term
"vote," with its potential unintended consequences:<br>
<font face="verdana"></font>
<dl>
<dl>
<dd>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.
<dd>â€â€¹
<dd><font color="#0000FF">If the Board
<dd>​
<dd>determines to take an action that is not consistent with </font>
<dd>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,
<dd>â€â€¹
<dd><font color="#0000FF">â€â‹such determination must be supported by
<dd>two-thirds of the Board,</font> 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.<font face="verdana">
<dd>â€â€¹</font>
</dl>
</dl>
<dd> <br>
<dd>I would appreciate your thoughts on this point and the revised
language. Thank you.<br><br>
<dd>Greg<br>
<dd>_______________________________________________<br>
<dd>Accountability-Cross-Community mailing list<br>
<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote><br>
</dl><br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
<a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote><br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
Accountability-Cross-Community@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote></body>
</html>