Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board?
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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
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@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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Greg, Agree entirely. This is not what I understood to be the intent of the ST 18 language. The more Paul and I have gone over this, the more concerned we have become over the language. We have expressed similar concerns in our public comment along with suggestions for alternative text. We need to fix this before moving forward. I fully admit to bearing part of the blame in this – we should have thought this through during the ST 18 discussions. But then we were under an enormous pressure to meet the deadline and text was being proposed on the fly during the Adobe chat sessions. The past few weeks have finally provided some time to reflect and think things through. That reflection should be taken into account. Best, Brett From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Greg Shatan Sent: Friday, December 18, 2015 12:52 AM To: Alan Greenberg Cc: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board? 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@mcgill.ca<mailto:alan.greenberg@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 ________________________________ Brett Schaefer Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org<http://heritage.org/> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://mm.icann.org/mailman/listinfo/accountability-cross-community>
Nothing needs to be added. el -- Sent from Dr Lisse's iPad mini
On 18 Dec 2015, at 16:54, Schaefer, Brett <Brett.Schaefer@heritage.org> wrote:
[...] I fully admit to bearing part of the blame in this – we should have thought this through during the ST 18 discussions. But then we were under an enormous pressure to meet the deadline and text was being proposed on the fly during the Adobe chat sessions. The past few weeks have finally provided some time to reflect and think things through. That reflection should be taken into account. [...]
As the issue of the role of the GAC within post-transition ICANN is the one most likely to cause Congressional (and perhaps even NTIA) opposition to the transition proposal -- if there is a perception of an unacceptable level of governmental influence over ICANN -- it is important to come to a common and acceptable understanding on this matter. As the ST18 subgroup came to an agreement only in the last few minutes of its final call it is perfectly understandable that there may be differing views on the text’s meaning. Greg raises an interesting question as to what happens if the GAC provides some very unpalatable advice and the Board neither advises the GAC that it intends to take an inconsistent action , or declines to take a formal vote when the GAC advice is of the consensus variety. Does the advice just wait in limbo indefinitely, or is there a point in time when it is deemed both accepted and in effect if the Board has declined to take any action? Philip S. Corwin, Founding Principal Virtualaw LLC 1155 F Street, NW Suite 1050 Washington, DC 20004 202-559-8597/Direct 202-559-8750/Fax 202-255-6172/cell Twitter: @VlawDC "Luck is the residue of design" -- Branch Rickey From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Schaefer, Brett Sent: Friday, December 18, 2015 9:55 AM To: Greg Shatan; Alan Greenberg Cc: accountability-cross-community@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, Agree entirely. This is not what I understood to be the intent of the ST 18 language. The more Paul and I have gone over this, the more concerned we have become over the language. We have expressed similar concerns in our public comment along with suggestions for alternative text. We need to fix this before moving forward. I fully admit to bearing part of the blame in this – we should have thought this through during the ST 18 discussions. But then we were under an enormous pressure to meet the deadline and text was being proposed on the fly during the Adobe chat sessions. The past few weeks have finally provided some time to reflect and think things through. That reflection should be taken into account. Best, Brett From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Greg Shatan Sent: Friday, December 18, 2015 12:52 AM To: Alan Greenberg Cc: accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board? 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@mcgill.ca<mailto:alan.greenberg@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) 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 ________________________________ Brett Schaefer Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org<http://heritage.org/> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2016.0.7227 / Virus Database: 4477/11098 - Release Date: 12/01/15 Internal Virus Database is out of date.
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@gmail.com<mailto:gregshatanipc@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@mcgill.ca<mailto:alan.greenberg@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) 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@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
On 18/12/2015 15:15, Drazek, Keith wrote:
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.
Is a presumption of acceptance not implicit in a rule that says you need 2/3 to object? I think this will change the relationship of the GAC to the Board, creating an expectation of acceptance. In any case, you offered it as a way of trying to win the GAC's support for the Recommendation on ST18 as a whole. Has it achieved that? Does the GAC now support this, as a package? 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 Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
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@icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of Keith Drazek <kdrazek@verisign.com<mailto:kdrazek@verisign.com>> Date: Friday, December 18, 2015 at 10:15 AM To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@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@gmail.com<mailto:gregshatanipc@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@mcgill.ca<mailto:alan.greenberg@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) 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@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
I don’t know about the Board, but I am pretty sure that the New gTLD Program Committee formally voted on GAC Advice J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: Steve DelBianco <sdelbianco@netchoice.org<mailto:sdelbianco@netchoice.org>> Date: Friday, December 18, 2015 at 10:28 AM To: Keith Drazek <kdrazek@verisign.com<mailto:kdrazek@verisign.com>>, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board? 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@icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of Keith Drazek <kdrazek@verisign.com<mailto:kdrazek@verisign.com>> Date: Friday, December 18, 2015 at 10:15 AM To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@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@gmail.com<mailto:gregshatanipc@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@mcgill.ca<mailto:alan.greenberg@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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_governance_bylaws-2Den_-23XI-2D2.1j&d=CwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=_CAoqs-TxnlnbeWVnwptIsHHPjN4Crv038A78XxLi2M&s=pOlKxXKH4pIWDpg0u-UNTNFFDpu2IsWwHflg46CoAa4&e=>) 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@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=_CAoqs-TxnlnbeWVnwptIsHHPjN4Crv038A78XxLi2M&s=HUbIifadAMShmEzCt90i8NLtPRnt1A4pm8XL2-bLCOg&e=> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=_CAoqs-TxnlnbeWVnwptIsHHPjN4Crv038A78XxLi2M&s=HUbIifadAMShmEzCt90i8NLtPRnt1A4pm8XL2-bLCOg&e=>
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@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@icann.org> on behalf of Keith Drazek <kdrazek@verisign.com> Date: Friday, December 18, 2015 at 10:15 AM To: Greg Shatan <gregshatanipc@gmail.com> Cc: "accountability-cross-community@icann.org" < accountability-cross-community@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@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@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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
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@icann.org [mailto:accountability-cross-community-bounces@icann.org] De la part de Greg Shatan Envoyé : vendredi 18 décembre 2015 17:30 À : Steve DelBianco Cc : accountability-cross-community@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@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@icann.org> on behalf of Keith Drazek <kdrazek@verisign.com> Date: Friday, December 18, 2015 at 10:15 AM To: Greg Shatan <gregshatanipc@gmail.com> Cc: "accountability-cross-community@icann.org" <accountability-cross-community@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@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@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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Fri, Dec 18, 2015 at 06:01:37PM +0100, Mathieu Weill wrote:
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) ?
I don't have any trouble imagining it, but perhaps this is because I work in communities where voting is not really the main decision-making mechanism. For instance, I can imagine a case where some matter has come before a group, and we have to deal with it, but initial discussion makes it pretty clear that people are not supportive of the idea. In such a case, I have no trouble imagining myself asking, "Does anyone wish to speak in _favour_ of this idea?" If nobody speaks up, I can imagine taking that as a pretty serious sign that there's just no support for the idea, and anything like a formal vote isn't necessary. Speaking as someone who sometimes has to evaluate the consensus of the Internet Architecture Board (note I'm not speaking _for_ them), I'm quite sure we make decisions this way pretty often. It's not our only way, but it's something for which I can think of examples in the past few months. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
If memory serves me correctly, the ICANN Board has formally rejected GAC advice only twice, and there may be some ambiguity about even those occasions. In 2008 the Board voted to move forward with the new gTLD program. I understand the GAC was not entirely in favor of this move, but I don’t know for certain whether the GAC had formally advised against it or whether their communications on that matter fell short of being formal advice. In any case, the Board vote was overwhelming and taken only after considerable effort across the entire community had proceeded for some years. In 2011, the first IRP action returned a decision that said the Board’s prior rejection of the .xxx application was incorrect. The GAC was opposed to the .xxx and the Board had to decide whether to accept or reject the IRP ruling. The entire history of the .xxx application was fairly messy, in my opinion, and there weren’t any clear, bright lines. I was vice chair of the Board at that time and found myself with the deciding vote. Although there were criticisms of the quality of the IRP ruling and although IRP rulings were not binding on the Board, I felt it would be a poor precedent to reject the very first IRP ruling and I voted to approve the .xxx application. We’re now headed toward binding IRP rulings and formal requirements for a 2/3 vote of the Board to reject GAC advice. Personally, I don’t have any trouble with either, but there will likely be occasions where the results are debatable. And, perhaps more to the point, whenever it’s possible to anticipate a conflict that might result in a formal rejection, informal consultation ahead of time is always advisable and often useful. If discussion within the Board indicates what the outcome of a formal vote will be, it’s sensible and constructive to share that with the affected parties before going through the formal process. Steve On Dec 18, 2015, at 12:01 PM, Mathieu Weill <mathieu.weill@afnic.fr> wrote:
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@icann.org [mailto:accountability-cross-community-bounces@icann.org] De la part de Greg Shatan Envoyé : vendredi 18 décembre 2015 17:30 À : Steve DelBianco Cc : accountability-cross-community@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@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@icann.org> on behalf of Keith Drazek <kdrazek@verisign.com> Date: Friday, December 18, 2015 at 10:15 AM To: Greg Shatan <gregshatanipc@gmail.com> Cc: "accountability-cross-community@icann.org" <accountability-cross-community@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@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@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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
it’s sensible and constructive to share that with the affected parties before going through the formal process.
+1 QED CW On 18 Dec 2015, at 18:42, Steve Crocker <steve.crocker@icann.org> wrote:
If memory serves me correctly, the ICANN Board has formally rejected GAC advice only twice, and there may be some ambiguity about even those occasions.
In 2008 the Board voted to move forward with the new gTLD program. I understand the GAC was not entirely in favor of this move, but I don’t know for certain whether the GAC had formally advised against it or whether their communications on that matter fell short of being formal advice. In any case, the Board vote was overwhelming and taken only after considerable effort across the entire community had proceeded for some years.
In 2011, the first IRP action returned a decision that said the Board’s prior rejection of the .xxx application was incorrect. The GAC was opposed to the .xxx and the Board had to decide whether to accept or reject the IRP ruling. The entire history of the .xxx application was fairly messy, in my opinion, and there weren’t any clear, bright lines. I was vice chair of the Board at that time and found myself with the deciding vote. Although there were criticisms of the quality of the IRP ruling and although IRP rulings were not binding on the Board, I felt it would be a poor precedent to reject the very first IRP ruling and I voted to approve the .xxx application.
We’re now headed toward binding IRP rulings and formal requirements for a 2/3 vote of the Board to reject GAC advice. Personally, I don’t have any trouble with either, but there will likely be occasions where the results are debatable. And, perhaps more to the point, whenever it’s possible to anticipate a conflict that might result in a formal rejection, informal consultation ahead of time is always advisable and often useful. If discussion within the Board indicates what the outcome of a formal vote will be, it’s sensible and constructive to share that with the affected parties before going through the formal process.
Steve
Begin forwarded message:
From: Christopher Wilkinson <lists@christopherwilkinson.eu> Subject: Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board? Date: 18 Dec 2015 19:01:58 GMT+01:00 To: "accountability-cross-community@icann.org Accountability" <accountability-cross-community@icann.org>
Good evening:
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.
Why?
More generally, this is an extraordinary debate among folk - whatever all their other merits - that have never been members of the GAC and have never been appointed to the ICANN Board.
Should the formal structures become so constraining - as a few CCWG participants appear to desire - then all that will have been achieved will be to thrust any serious issues between the Community, the Board and the GAC out of the designated procedures and into purely informal contexts. That would inevitably result in a serious loss of transparency, which was however the primary objective in the first place. There is a word for that.
Hey, Guys, let's get real …
CW
On 18 Dec 2015, at 17:29, Greg Shatan <gregshatanipc@gmail.com> wrote:
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Dec 18, 2015, at 12:01 PM, Mathieu Weill <mathieu.weill@afnic.fr> wrote:
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@icann.org [mailto:accountability-cross-community-bounces@icann.org] De la part de Greg Shatan Envoyé : vendredi 18 décembre 2015 17:30 À : Steve DelBianco Cc : accountability-cross-community@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@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@icann.org> on behalf of Keith Drazek <kdrazek@verisign.com> Date: Friday, December 18, 2015 at 10:15 AM To: Greg Shatan <gregshatanipc@gmail.com> Cc: "accountability-cross-community@icann.org" <accountability-cross-community@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@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@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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Mathieu, I think Steve has now answered you more authoritatively than I could. Other current and former Board members could provide their perspectives as well. This type of flexibility was clearly contemplated when the [current] Bylaws were drafted. Consider this sentence: " 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 this "determination" was intended to only be by formal vote, why not say so? The Bylaws are not shy about using the words "vote" and "voting." Why choose this unique construction in this one place in all the Bylaws if all you meant was "vote"? If all that was contemplated by a vote, why have a separate requirement to inform and to state reasons? A formal vote will always be publicly reported, supported by a motion and rationale, so information/reasons would be taken care of by ordinary procedures? To my mind, this is stated so that the GAC is kept informed in the absence of a formal vote (or more to the point, as the Board sees that it is heading toward a negative vote and wants to engage in the "mutually acceptable solution" process. For the moment, I won't touch the difference between "rejection" and "determining to take an action not consistent" with something, but that is a real distinction. If we think this has been and should be an all-voting, all-the-time process (and I think Steve's email shows us otherwise), perhaps the Bylaw should (or would) look like this: 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 votes to reject Governmental Advisory Committee advice, it shall provide the Committee the motion and rationale stating the reasons why it decided to reject that advice. 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. But it doesn't. I'm sure you don't like finding a hole in the boat, and frankly I don't like it either. But boats do one thing when holes are plugged and another thing when holes are neglected. "Done is better than perfect" is a useful mantra. But so is "Sin in haste, repent at leisure." Greg On Fri, Dec 18, 2015 at 12:01 PM, Mathieu Weill <mathieu.weill@afnic.fr> wrote:
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@icann.org [mailto: accountability-cross-community-bounces@icann.org] *De la part de* Greg Shatan *Envoyé :* vendredi 18 décembre 2015 17:30 *À :* Steve DelBianco *Cc :* accountability-cross-community@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@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@icann.org> on behalf of Keith Drazek <kdrazek@verisign.com> *Date: *Friday, December 18, 2015 at 10:15 AM *To: *Greg Shatan <gregshatanipc@gmail.com> *Cc: *"accountability-cross-community@icann.org" < accountability-cross-community@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@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@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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Grec I have followed this lengthy and inefficient exchange of e- mails since the last 10 days. While I am not comfortable to see such an insistence,I agree to simply replace " determined" by vote and end this lengthy discussion. I strongly disagree not to refer to the need that after non acceptance of the GAC advice , The Board shall so inform the GAC ( The second part of your last message ) In fact the obligation to inform the GAC. that its Advice was rejected is fundamental in order that both partied get into negotiations to find a satisfactory solution. Publicly available BORAD ,s decision is not sufficient to trigger the negotiation between Board and GAC Regards Kavouss Sent from my iPhone
On 18 Dec 2015, at 19:59, Greg Shatan <gregshatanipc@gmail.com> wrote:
Mathieu,
I think Steve has now answered you more authoritatively than I could. Other current and former Board members could provide their perspectives as well.
This type of flexibility was clearly contemplated when the [current] Bylaws were drafted. Consider this sentence: " 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 this "determination" was intended to only be by formal vote, why not say so? The Bylaws are not shy about using the words "vote" and "voting." Why choose this unique construction in this one place in all the Bylaws if all you meant was "vote"?
If all that was contemplated by a vote, why have a separate requirement to inform and to state reasons? A formal vote will always be publicly reported, supported by a motion and rationale, so information/reasons would be taken care of by ordinary procedures? To my mind, this is stated so that the GAC is kept informed in the absence of a formal vote (or more to the point, as the Board sees that it is heading toward a negative vote and wants to engage in the "mutually acceptable solution" process.
For the moment, I won't touch the difference between "rejection" and "determining to take an action not consistent" with something, but that is a real distinction.
If we think this has been and should be an all-voting, all-the-time process (and I think Steve's email shows us otherwise), perhaps the Bylaw should (or would) look like this:
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 votes to reject Governmental Advisory Committee advice, it shall provide the Committee the motion and rationale stating the reasons why it decided to reject that advice. 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.
But it doesn't.
I'm sure you don't like finding a hole in the boat, and frankly I don't like it either. But boats do one thing when holes are plugged and another thing when holes are neglected. "Done is better than perfect" is a useful mantra. But so is "Sin in haste, repent at leisure."
Greg
On Fri, Dec 18, 2015 at 12:01 PM, Mathieu Weill <mathieu.weill@afnic.fr> wrote: 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@icann.org [mailto:accountability-cross-community-bounces@icann.org] De la part de Greg Shatan Envoyé : vendredi 18 décembre 2015 17:30 À : Steve DelBianco Cc : accountability-cross-community@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@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@icann.org> on behalf of Keith Drazek <kdrazek@verisign.com> Date: Friday, December 18, 2015 at 10:15 AM To: Greg Shatan <gregshatanipc@gmail.com> Cc: "accountability-cross-community@icann.org" <accountability-cross-community@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@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@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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Kavouss, Thank you for your email. Perhaps I did not make myself clear enough. The language you are responding to is not what I propose; rather it is language that I believe more clearly expresses the intentions of some to force the board into voting and into "rejecting" GAC advice. I am not one who shares those intentions and I think many others who initially supported the Third Draft language do not share this intention either. This "disconnect" is the reason I started this thread, and I think that more participants are now seeing that the Third Draft language does more than merely raise a threshold from majority to 2/3. To be more specific, I am not suggesting that "determined" be replaced by "vote," and such an outcome would be the exact opposite of what I contend should happen here. So, I am sorry that your kind offer will not end this lengthy discussion. I am of course fine with maintaining the obligation of the Board to inform the GAC when it determines that it will take an action inconsistent with GAC advice -- which is not the same as "rejecting" GAC advice, by the way. The point is that the Board's "determination to take an action inconsistent with GAC advice" may not always take the form of a vote, and thus may not always produce the type of public notice that a Board vote will trigger. However, it seems that some in the CCWG want to force the Board into voting on GAC advice, to making any ICANN action inconsistent with GAC advice a "rejection" of the GAC, and possibly making it so that all GAC advice is accepted unless it is rejected by Board vote. I don't think is a consensus position of the CCWG, but right now we have language in the Third Draft proposal which can be read to do all these things. And that is why this thread is needed. Greg On Sat, Dec 19, 2015 at 3:51 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Grec I have followed this lengthy and inefficient exchange of e- mails since the last 10 days. While I am not comfortable to see such an insistence,I agree to simply replace " determined" by vote and end this lengthy discussion. I strongly disagree not to refer to the need that after non acceptance of the GAC advice , The Board shall so inform the GAC ( The second part of your last message ) In fact the obligation to inform the GAC. that its Advice was rejected is fundamental in order that both partied get into negotiations to find a satisfactory solution. Publicly available BORAD ,s decision is not sufficient to trigger the negotiation between Board and GAC Regards Kavouss
Sent from my iPhone
On 18 Dec 2015, at 19:59, Greg Shatan <gregshatanipc@gmail.com> wrote:
Mathieu,
I think Steve has now answered you more authoritatively than I could. Other current and former Board members could provide their perspectives as well.
This type of flexibility was clearly contemplated when the [current] Bylaws were drafted. Consider this sentence: " 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 this "determination" was intended to only be by formal vote, why not say so? The Bylaws are not shy about using the words "vote" and "voting." Why choose this unique construction in this one place in all the Bylaws if all you meant was "vote"?
If all that was contemplated by a vote, why have a separate requirement to inform and to state reasons? A formal vote will always be publicly reported, supported by a motion and rationale, so information/reasons would be taken care of by ordinary procedures? To my mind, this is stated so that the GAC is kept informed in the absence of a formal vote (or more to the point, as the Board sees that it is heading toward a negative vote and wants to engage in the "mutually acceptable solution" process.
For the moment, I won't touch the difference between "rejection" and "determining to take an action not consistent" with something, but that is a real distinction.
If we think this has been and should be an all-voting, all-the-time process (and I think Steve's email shows us otherwise), perhaps the Bylaw should (or would) look like this:
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 votes to reject Governmental Advisory Committee advice, it shall provide the Committee the motion and rationale stating the reasons why it decided to reject that advice. 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.
But it doesn't.
I'm sure you don't like finding a hole in the boat, and frankly I don't like it either. But boats do one thing when holes are plugged and another thing when holes are neglected. "Done is better than perfect" is a useful mantra. But so is "Sin in haste, repent at leisure."
Greg
On Fri, Dec 18, 2015 at 12:01 PM, Mathieu Weill <mathieu.weill@afnic.fr> wrote:
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@icann.org [mailto: accountability-cross-community-bounces@icann.org] *De la part de* Greg Shatan *Envoyé :* vendredi 18 décembre 2015 17:30 *À :* Steve DelBianco *Cc :* accountability-cross-community@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@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@icann.org> on behalf of Keith Drazek <kdrazek@verisign.com> *Date: *Friday, December 18, 2015 at 10:15 AM *To: *Greg Shatan <gregshatanipc@gmail.com> *Cc: *"accountability-cross-community@icann.org" < accountability-cross-community@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@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@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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I think it is also worth pointing out that this last minute “compromise” on stress test 18, which is now causing so many “second thoughts” from the community, is largely the result of an arbitrary "straw poll" of people in a single online meeting (the majority of whom were GAC) and NOT from a poll of the appointed Members of the CCWG-Accountability. I’m sorry to have to say it, but it is a flaw in our process. Robin
On Dec 18, 2015, at 8:29 AM, Greg Shatan <gregshatanipc@gmail.com> wrote:
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@netchoice.org <mailto:sdelbianco@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@icann.org <mailto:accountability-cross-community-bounces@icann.org>> on behalf of Keith Drazek <kdrazek@verisign.com <mailto:kdrazek@verisign.com>> Date: Friday, December 18, 2015 at 10:15 AM To: Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> Cc: "accountability-cross-community@icann.org <mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org <mailto:accountability-cross-community@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@gmail.com <mailto:gregshatanipc@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@mcgill.ca <mailto:alan.greenberg@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@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Good evening:
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.
Why? More generally, this is an extraordinary debate among folk - whatever all their other merits - that have never been members of the GAC and have never been appointed to the ICANN Board. Should the formal structures become so constraining - as a few CCWG participants appear to desire - then all that will have been achieved will be to thrust any serious issues between the Community, the Board and the GAC out of the designated procedures and into purely informal contexts. That would inevitably result in a serious loss of transparency, which was however the primary objective in the first place. There is a word for that. Hey, Guys, let's get real … CW On 18 Dec 2015, at 17:29, Greg Shatan <gregshatanipc@gmail.com> wrote:
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. Robin
On Dec 17, 2015, at 9:51 PM, Greg Shatan <gregshatanipc@gmail.com> wrote:
[…]
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@mcgill.ca <mailto:alan.greenberg@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@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
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. Alan At 18/12/2015 01:11 PM, Robin Gross wrote:
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.
Robin
On Dec 17, 2015, at 9:51 PM, Greg Shatan <<mailto:gregshatanipc@gmail.com>gregshatanipc@gmail.com> wrote:
[ ]
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 <<mailto:alan.greenberg@mcgill.ca>alan.greenberg@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) 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 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.
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 <mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list <mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Alan, if we’re comparing results of GNSO PDP recommendations with GAC consensus advice, it’s important to note that a key element of the GNSO’s threshold is the Board only has to show deference to the GNSO when that advice is the result of a formal PDP. This means not all GNSO resolutions receive the Board deference, even if the vote of the GNSO Council is unanimous. The GNSO may only initiate a formal PDP under certain restrictions in both scope and jurisdiction and not every topic can be properly considered in scope for a GNSO PDP. In fact, as part of every issue report in the GNSO PDP process, the ICANN General Counsel is asked to opine as to whether the proposed issue is properly within the jurisdiction of the GNSO. If it is not, that does not prevent the PDP from continuing, but the higher Board threshold would not be required in such a case. Will the GAC be similarly and appropriately restricted in the scope of its advice, for example, to only issues of public policy or international law and treaties? This issue is under active discussion in the RySG and will be reflected in its public comments. Regards, Keith From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Friday, December 18, 2015 1:28 PM To: Robin Gross; Greg Shatan Cc: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board? 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. Alan At 18/12/2015 01:11 PM, Robin Gross wrote: 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. Robin On Dec 17, 2015, at 9:51 PM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> > wrote: […] 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@mcgill.ca<mailto:alan.greenberg@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) 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 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. 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@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
Just as a clarification: since las summer there is also a GNSO Guidance procedure with identical 2/3 rejection threshhold. regards Jorge Von meinem iPhone gesendet Am 18.12.2015 um 19:48 schrieb Drazek, Keith <kdrazek@verisign.com<mailto:kdrazek@verisign.com>>: Alan, if we’re comparing results of GNSO PDP recommendations with GAC consensus advice, it’s important to note that a key element of the GNSO’s threshold is the Board only has to show deference to the GNSO when that advice is the result of a formal PDP. This means not all GNSO resolutions receive the Board deference, even if the vote of the GNSO Council is unanimous. The GNSO may only initiate a formal PDP under certain restrictions in both scope and jurisdiction and not every topic can be properly considered in scope for a GNSO PDP. In fact, as part of every issue report in the GNSO PDP process, the ICANN General Counsel is asked to opine as to whether the proposed issue is properly within the jurisdiction of the GNSO. If it is not, that does not prevent the PDP from continuing, but the higher Board threshold would not be required in such a case. Will the GAC be similarly and appropriately restricted in the scope of its advice, for example, to only issues of public policy or international law and treaties? This issue is under active discussion in the RySG and will be reflected in its public comments. Regards, Keith From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Friday, December 18, 2015 1:28 PM To: Robin Gross; Greg Shatan Cc: accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board? 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. Alan At 18/12/2015 01:11 PM, Robin Gross wrote: 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. Robin On Dec 17, 2015, at 9:51 PM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> > wrote: […] 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@mcgill.ca<mailto:alan.greenberg@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) 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 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. 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@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
Alan I do not clearly understand your argument in saying " if a given issue required 2/3 majority to be rejected by the Board, then to accept the same issue, the Board requires 1/3 vote " There is no logic in that example? Regards Kavouss Sent from my iPhone
On 18 Dec 2015, at 20:24, <Jorge.Cancio@bakom.admin.ch> <Jorge.Cancio@bakom.admin.ch> wrote:
Just as a clarification: since las summer there is also a GNSO Guidance procedure with identical 2/3 rejection threshhold.
regards
Jorge
Von meinem iPhone gesendet
Am 18.12.2015 um 19:48 schrieb Drazek, Keith <kdrazek@verisign.com<mailto:kdrazek@verisign.com>>:
Alan, if we’re comparing results of GNSO PDP recommendations with GAC consensus advice, it’s important to note that a key element of the GNSO’s threshold is the Board only has to show deference to the GNSO when that advice is the result of a formal PDP. This means not all GNSO resolutions receive the Board deference, even if the vote of the GNSO Council is unanimous. The GNSO may only initiate a formal PDP under certain restrictions in both scope and jurisdiction and not every topic can be properly considered in scope for a GNSO PDP. In fact, as part of every issue report in the GNSO PDP process, the ICANN General Counsel is asked to opine as to whether the proposed issue is properly within the jurisdiction of the GNSO. If it is not, that does not prevent the PDP from continuing, but the higher Board threshold would not be required in such a case. Will the GAC be similarly and appropriately restricted in the scope of its advice, for example, to only issues of public policy or international law and treaties? This issue is under active discussion in the RySG and will be reflected in its public comments. Regards, Keith
From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Friday, December 18, 2015 1:28 PM To: Robin Gross; Greg Shatan Cc: accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board?
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.
Alan
At 18/12/2015 01:11 PM, Robin Gross wrote:
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.
Robin
On Dec 17, 2015, at 9:51 PM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> > wrote:
[…]
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@mcgill.ca<mailto:alan.greenberg@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) 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 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. 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@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I will try again. What I am saying is just a mathematical truth. I a Bylaw says that to REJECT something (whether it is GAC Advice or a GNSO PDP Recommendation or where to go have dinner) at least 2/3 of the Board must reject. That is, 1/3 or less of the Board opt to accept. If the Board does NOT reject, then it means that less that 2/3 voted to reject. That is mathematically identical to greater than 1/3 accepts, sine the total must be 1. Alan At 19/12/2015 03:39 AM, Kavouss Arasteh wrote:
Alan I do not clearly understand your argument in saying " if a given issue required 2/3 majority to be rejected by the Board, then to accept the same issue, the Board requires 1/3 vote " There is no logic in that example? Regards Kavouss
Not at all. You are ignoring extensions. But then, you showed you didn't understand the concept of abstention when we discussed the Community Process.
On 19 Dec 2015, at 20:41, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
I will try again. What I am saying is just a mathematical truth.
I a Bylaw says that to REJECT something (whether it is GAC Advice or a GNSO PDP Recommendation or where to go have dinner) at least 2/3 of the Board must reject. That is, 1/3 or less of the Board opt to accept. If the Board does NOT reject, then it means that less that 2/3 voted to reject. That is mathematically identical to greater than 1/3 accepts, sine the total must be 1.
Alan
At 19/12/2015 03:39 AM, Kavouss Arasteh wrote:
Alan I do not clearly understand your argument in saying " if a given issue required 2/3 majority to be rejected by the Board, then to accept the same issue, the Board requires 1/3 vote " There is no logic in that example? Regards Kavouss
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I think if we bring abstentions into the equation, Alan's point seems to be stronger, rather than weaker. We have a Board of 16 voting directors. A 2/3 majority is 11 (11/16 = 68.75%). (By contrast, a simple majority is 9 (50%+1).) Thus 11 Board members must vote to reject an item of GAC Advice under the proposed Bylaw. If 10 (62.5%) (or fewer) Board members vote to reject, Advice is (presumably) "accepted." Under this scenario, with no abstentions, 6 members (37.5%) have voted to accept (or, at least, not to reject) GAC Advice; thus, ICANN must abide by advice that supported by only 6 out of 16 Directors. And that is the best case scenario when a vote to reject falls just short. Under this same scenario, with 10 votes to reject, and 5 members vote to accept the advice and 1 abstains, we now have 31.25% of the Board in favor of the advice we must all abide by. If there are 2 abstentions and 4 in favor, the percentage in support drops to 25% (and then to 18.75%, 12.5%, 6.25% and 0% as abstentions increase). If only 9 members vote to reject (a simple majority) and none abstain, then the accepted advice is supported by at most 43.75 of the Board. If one abstains, the percent in support is 37.5% and so forth. If only 8 members vote to reject, at best 50% of the Board supports the advice. If one abstains, that drops to 43.75% and so forth. If only 7 members vote to reject, we finally get to the point where the majority of the Board supports the Advice (best case scenario, assuming no abstentions). With one abstention, that drops to 50% and so forth. Greg On Sat, Dec 19, 2015 at 6:47 PM, Malcolm Hutty <malcolm@linx.net> wrote:
Not at all. You are ignoring extensions. But then, you showed you didn't understand the concept of abstention when we discussed the Community Process.
On 19 Dec 2015, at 20:41, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
I will try again. What I am saying is just a mathematical truth.
I a Bylaw says that to REJECT something (whether it is GAC Advice or a GNSO PDP Recommendation or where to go have dinner) at least 2/3 of the Board must reject. That is, 1/3 or less of the Board opt to accept. If the Board does NOT reject, then it means that less that 2/3 voted to reject. That is mathematically identical to greater than 1/3 accepts, sine the total must be 1.
Alan
At 19/12/2015 03:39 AM, Kavouss Arasteh wrote:
Alan I do not clearly understand your argument in saying " if a given issue required 2/3 majority to be rejected by the Board, then to accept the same issue, the Board requires 1/3 vote " There is no logic in that example? Regards Kavouss
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Malcolm, you are correct hat I did not address how abstentions would impact this. Mea Culpa. That being said, I would greatly appreciate NOT having personal slurs from you. If you cannot keep this at a civil level, please do not post. I happen to be VERY aware about how abstentions are treated, to the extent that I know that they are handled VERY differently in varying organizations and in fact at times within the same body. Alan At 19/12/2015 06:47 PM, Malcolm Hutty wrote:
Not at all. You are ignoring extensions. But then, you showed you didn't understand the concept of abstention when we discussed the Community Process.
On 19 Dec 2015, at 20:41, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
I will try again. What I am saying is just a mathematical truth.
I a Bylaw says that to REJECT something (whether it is GAC Advice or a GNSO PDP Recommendation or where to go have dinner) at least 2/3 of the Board must reject. That is, 1/3 or less of the Board opt to accept. If the Board does NOT reject, then it means that less that 2/3 voted to reject. That is mathematically identical to greater than 1/3 accepts, sine the total must be 1.
Alan
At 19/12/2015 03:39 AM, Kavouss Arasteh wrote:
Alan I do not clearly understand your argument in saying " if a given issue required 2/3 majority to be rejected by the Board, then to accept the same issue, the Board requires 1/3 vote " There is no logic in that example? Regards Kavouss
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Robin Grec ,s issue of "determined"versus "voted "With 2/3 majority against is totally a different issue than what you raised in yr message. I do not understand your point! May you pls clarify it? Regards Kavouss Sent from my iPhone
On 18 Dec 2015, at 19:11, Robin Gross <robin@ipjustice.org> wrote:
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.
Robin
On Dec 17, 2015, at 9:51 PM, Greg Shatan <gregshatanipc@gmail.com> wrote:
[…]
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@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) 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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
participants (16)
-
Alan Greenberg -
Andrew Sullivan -
Burr, Becky -
Christopher Wilkinson -
Dr Eberhard W Lisse -
Drazek, Keith -
Greg Shatan -
Jorge.Cancio＠bakom.admin.ch -
Kavouss Arasteh -
Malcolm Hutty -
Mathieu Weill -
Phil Corwin -
Robin Gross -
Schaefer, Brett -
Steve Crocker -
Steve DelBianco