Re: [Area 3] [Party1] additional bylaws change for your Community Empowerment document
Dear All, Please carefully consider what we are proposing, Please be prudent and do not hurry up to change one of the most critical, delicate and vital issue changing b" Consensus" tp " Majority" This is a GAC issue and you need to clearly and specifically seek formal opinion of GAC. Regards Kavouss 2015-02-18 13:03 GMT+01:00 Roelof Meijer <Roelof.Meijer@sidn.nl>:
Steve,
"What you describe is the situation in the GAC today”.. Exactly, but the GAC can still provide (non-consensus) advice that ICANN must consider and respond to. With the suggested amendment we risk getting into a situation, that can only be broken by the alternative: giving the community standing to veto a board decision:
example stress test:
- The GAC provides sound (in the public interest) but non-consensus advice on an important matter; - The ICANN board, referring to the (now amended) bylaws decides not to consider nor to respond to the advice, and /or uses the fact that the GAC has no consensus on its position, to take a decision on the matter that is contrary to the GAC advice; - Community veto needed to remedy
So in the end I wonder if the bylaws amendment and community veto are alternatives, as it would seem that with the bylaw amendment we still need community veto in „opposite” situations (good GAC advice vs bad GAC advice). If that is true, we might as well forget about the amendment
Cheers,
Roelof
From: Steve DelBianco <sdelbianco@netchoice.org> Date: woensdag 18 februari 2015 12:09 To: Roelof Meijer <roelof.meijer@sidn.nl> Cc: "acct-staff@icann.org" <acct-staff@icann.org>, "wp1@icann.org" < wp1@icann.org> Subject: Re: [Party1] additional bylaws change for your Community Empowerment document
Roelof,
What you describe is the situation in the GAC today, where a single government can object and thereby deny consensus. The GAC presently uses this definition: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”
Indeed, this has occurred during GAC debate on several new gTLD objections, moving some in the GAC to suggest they change to majority voting instead of consensus.
We are considering amending ICANN bylaws so that due deference is reserved for GAC advice that is truly consensus. If we did, let’s understand that the GAC might still send over advice that is supported by many but not a consensus. ICANN would not be obliged to give due deference, but ICANN could still implement the advice if it were supported by the broader community. So I don’t see that good advice would go to waste.
Best, Steve
From: Roelof Meijer Date: Wednesday, February 18, 2015 at 5:59 AM To: Steve DelBianco Cc: "acct-staff@icann.org", "wp1@icann.org" Subject: Re: [Party1] additional bylaws change for your Community Empowerment document
Steve,
I assume you did consider that the option of amending ICANN's bylaws to give due deference only to GAC consensus advice might also work against the public interest, if the advice is in the public interest but not a consensus advice? The amendment introduces the risk of „capture” of GAC advice by a single GAC member
Best,
Roelof
From: Steve DelBianco <sdelbianco@netchoice.org> Date: maandag 16 februari 2015 21:52 To: Jordan Carter <jordan@internetnz.net.nz> Cc: "acct-staff@icann.org" <acct-staff@icann.org>, "wp1@icann.org" < wp1@icann.org> Subject: [Party1] additional bylaws change for your Community Empowerment document
Jordan — while applying a stress test, we discovered a community empowerment measure that was in the Inventory, but wasn’t yet reflected in your Community Empowerment document.
This item could go into the table of Community Powers for Consideration:
Amend ICANN bylaws (Section XI 1j) to give due deference only to GAC consensus advice, and add a definition of “consensus”, such as “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”
This item was prompted by stress test #18 in Category IV, regarding GAC Advice:
18. Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting for advice to ICANN’s board.
Consequence: Under current bylaws, ICANN must consider and respond to GAC advice, even if that advice were not supported by consensus. A majority of governments could thereby approve GAC advice that restricted free online expression, for example.
Existing Accountability Measures:
Current ICANN Bylaws (Section XI) give due deference to GAC advice, including a requirement to try and find “a mutually acceptable solution.”
This is required for any GAC advice, not just for GAC consensus advice.
Today, GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.” But the GAC may at any time change its procedures to use majority voting instead of consensus.
CCWG Proposed Accountability Measures:
One proposed measure is to give the community standing to veto a board decision. If ICANN board acquiesced to GAC advice that was not supported by GAC consensus, the community veto could enable reversal of that decision.
Another proposed measure is to amend ICANN bylaws (Section XI 1j) to give due deference only to GAC consensus advice, and add a definition of “consensus”.
The GAC could change its Operating Principle 47 to use majority voting for formal GAC advice, but ICANN bylaws would require due deference only to advice that had GAC consensus.
Best, Steve — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org <http://www.netchoice.org/> and http://blog.netchoice.org +1.703.615.6206
_______________________________________________ WP1 mailing list WP1@icann.org https://mm.icann.org/mailman/listinfo/wp1
Hi, It seems to me that we cannot define what consensus means to the GAC. That would be their own bottom-up privilege. What perhaps can be defined in the the bylaws, is at what threshold the advice triggers the special GAC advice clause. avri On 18-Feb-15 10:16, Kavouss Arasteh wrote:
Dear All, Please carefully consider what we are proposing, Please be prudent and do not hurry up to change one of the most critical, delicate and vital issue changing b" Consensus" tp " Majority" This is a GAC issue and you need to clearly and specifically seek formal opinion of GAC. Regards Kavouss
2015-02-18 13:03 GMT+01:00 Roelof Meijer <Roelof.Meijer@sidn.nl <mailto:Roelof.Meijer@sidn.nl>>:
Steve,
"What you describe is the situation in the GAC today”.. Exactly, but the GAC can still provide (non-consensus) advice that ICANN must consider and respond to. With the suggested amendment we risk getting into a situation, that can only be broken by the alternative: giving the community standing to veto a board decision:
example stress test:
* The GAC provides sound (in the public interest) but non-consensus advice on an important matter; * The ICANN board, referring to the (now amended) bylaws decides not to consider nor to respond to the advice, and /or uses the fact that the GAC has no consensus on its position, to take a decision on the matter that is contrary to the GAC advice; * Community veto needed to remedy
So in the end I wonder if the bylaws amendment and community veto are alternatives, as it would seem that with the bylaw amendment we still need community veto in „opposite” situations (good GAC advice vs bad GAC advice). If that is true, we might as well forget about the amendment
Cheers,
Roelof
From: Steve DelBianco <sdelbianco@netchoice.org <mailto:sdelbianco@netchoice.org>> Date: woensdag 18 februari 2015 12:09 To: Roelof Meijer <roelof.meijer@sidn.nl <mailto:roelof.meijer@sidn.nl>> Cc: "acct-staff@icann.org <mailto:acct-staff@icann.org>" <acct-staff@icann.org <mailto:acct-staff@icann.org>>, "wp1@icann.org <mailto:wp1@icann.org>" <wp1@icann.org <mailto:wp1@icann.org>> Subject: Re: [Party1] additional bylaws change for your Community Empowerment document
Roelof,
What you describe is the situation in the GAC today, where a single government can object and thereby deny consensus. The GAC presently uses this definition: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”
Indeed, this has occurred during GAC debate on several new gTLD objections, moving some in the GAC to suggest they change to majority voting instead of consensus.
We are considering amending ICANN bylaws so that due deference is reserved for GAC advice that is truly consensus. If we did, let’s understand that the GAC might still send over advice that is supported by many but not a consensus. ICANN would not be obliged to give due deference, but ICANN could still implement the advice if it were supported by the broader community. So I don’t see that good advice would go to waste.
Best, Steve
From: Roelof Meijer Date: Wednesday, February 18, 2015 at 5:59 AM To: Steve DelBianco Cc: "acct-staff@icann.org <mailto:acct-staff@icann.org>", "wp1@icann.org <mailto:wp1@icann.org>" Subject: Re: [Party1] additional bylaws change for your Community Empowerment document
Steve,
I assume you did consider that the option of amending ICANN's bylaws to give due deference only to GAC consensus advice might also work against the public interest, if the advice is in the public interest but not a consensus advice? The amendment introduces the risk of „capture” of GAC advice by a single GAC member
Best,
Roelof
From: Steve DelBianco <sdelbianco@netchoice.org <mailto:sdelbianco@netchoice.org>> Date: maandag 16 februari 2015 21:52 To: Jordan Carter <jordan@internetnz.net.nz <mailto:jordan@internetnz.net.nz>> Cc: "acct-staff@icann.org <mailto:acct-staff@icann.org>" <acct-staff@icann.org <mailto:acct-staff@icann.org>>, "wp1@icann.org <mailto:wp1@icann.org>" <wp1@icann.org <mailto:wp1@icann.org>> Subject: [Party1] additional bylaws change for your Community Empowerment document
Jordan — while applying a stress test, we discovered a community empowerment measure that was in the Inventory, but wasn’t yet reflected in your Community Empowerment document.
This item could go into the table of Community Powers for Consideration:
Amend ICANN bylaws (Section XI 1j) to give due deference only to GAC consensus advice, and add a definition of “consensus”, such as “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”
This item was prompted by stress test #18 in Category IV, regarding GAC Advice:
18. Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting for advice to ICANN’s board.
Consequence: Under current bylaws, ICANN must consider and respond to GAC advice, even if that advice were not supported by consensus. A majority of governments could thereby approve GAC advice that restricted free online expression, for example.
Existing Accountability Measures:
Current ICANN Bylaws (Section XI) give due deference to GAC advice, including a requirement to try and find “a mutually acceptable solution.”
This is required for any GAC advice, not just for GAC consensus advice.
Today, GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.” But the GAC may at any time change its procedures to use majority voting instead of consensus.
CCWG Proposed Accountability Measures:
One proposed measure is to give the community standing to veto a board decision. If ICANN board acquiesced to GAC advice that was not supported by GAC consensus, the community veto could enable reversal of that decision.
Another proposed measure is to amend ICANN bylaws (Section XI 1j) to give due deference only to GAC consensus advice, and add a definition of “consensus”.
The GAC could change its Operating Principle 47 to use majority voting for formal GAC advice, but ICANN bylaws would require due deference only to advice that had GAC consensus.
Best, Steve — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org <http://www.netchoice.org/> and http://blog.netchoice.org <http://blog.netchoice.org/> +1.703.615.6206 <tel:%2B1.703.615.6206>
_______________________________________________ WP1 mailing list WP1@icann.org <mailto:WP1@icann.org> https://mm.icann.org/mailman/listinfo/wp1
_______________________________________________ Ccwg-accountability3 mailing list Ccwg-accountability3@icann.org https://mm.icann.org/mailman/listinfo/ccwg-accountability3
This proposal does not in any way curtail the ability of the GAC to change the threshold for decision-making from consensus (by the current GAC definition) to some other, lower threshold. The GAC is free to do so, and to make some decisions or all decisions by majority rule rather than GAC consensus The proposal merely states that, if the GAC issues advice to the Board that was approved by a method with a lower threshold than current GAC consensus, such advice will not be given the same level of deference as consensus GAC advice.is given under Section XI.2.1.j of the ICANN Bylaws (excerpted below). The Board will still be free to consider and to adopt such non-consensus advice; it just won't have to follow the rubric of XI.2.1.j. Specifically, it could reject such advice by majority vote, and would not need to go into consultation to find a "mutually acceptable solution." Notably, while this would require a change to the ICANN Bylaws, it would not require any change to the GAC's own procedures. There is ample precedent for this two-tier approval structure in the Bylaws. Specifically, in Annex A, Section 9.a (also excerpted below) sets a higher threshold (2/3 against) for the Board to reject a GNSO policy recommendation approved by a Supermajority vote of the GNSO Council, and a lower threshold (majority against) for the Board to reject a GNSO policy recommendation approved by less than a Supermajority vote of the GNSO Council. (Note that, in either case, the Working Group that prepared the policy recommendation would have approved it by consensus.) Given the above, it would seem odd for the GAC to expect the same level of deference for non-consensus advice as it enjoys for consensus advice. As such, this proposal should not be especially surprising, even if it may not be especially welcome. Clearly, we should get feedback from the GAC, through their members and participants in this CCWG on this and other proposals (whether or not they have any effect on the GAC), and we should keep in mind that the GAC is a chartering organization of this CCWG, and thus an organization whose approval of any final proposal is highly desirable. However, given that this is not a proposed change to GAC procedure but rather a proposed change to the ICANN Bylaws, I do not think that a formal opinion of the GAC is needed. Best regards, Greg XI.2.1.j: j. 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. 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. Annex A, 9.a: a. Any PDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN. If the GNSO Council recommendation was approved by less than a GNSO Supermajority Vote, a majority vote of the Board will be sufficient to determine that such policy is not in the best interests of the ICANNcommunity or ICANN. On Wed, Feb 18, 2015 at 10:16 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com
wrote:
Dear All, Please carefully consider what we are proposing, Please be prudent and do not hurry up to change one of the most critical, delicate and vital issue changing b" Consensus" tp " Majority" This is a GAC issue and you need to clearly and specifically seek formal opinion of GAC. Regards Kavouss
2015-02-18 13:03 GMT+01:00 Roelof Meijer <Roelof.Meijer@sidn.nl>:
Steve,
"What you describe is the situation in the GAC today”.. Exactly, but the GAC can still provide (non-consensus) advice that ICANN must consider and respond to. With the suggested amendment we risk getting into a situation, that can only be broken by the alternative: giving the community standing to veto a board decision:
example stress test:
- The GAC provides sound (in the public interest) but non-consensus advice on an important matter; - The ICANN board, referring to the (now amended) bylaws decides not to consider nor to respond to the advice, and /or uses the fact that the GAC has no consensus on its position, to take a decision on the matter that is contrary to the GAC advice; - Community veto needed to remedy
So in the end I wonder if the bylaws amendment and community veto are alternatives, as it would seem that with the bylaw amendment we still need community veto in „opposite” situations (good GAC advice vs bad GAC advice). If that is true, we might as well forget about the amendment
Cheers,
Roelof
From: Steve DelBianco <sdelbianco@netchoice.org> Date: woensdag 18 februari 2015 12:09 To: Roelof Meijer <roelof.meijer@sidn.nl> Cc: "acct-staff@icann.org" <acct-staff@icann.org>, "wp1@icann.org" < wp1@icann.org> Subject: Re: [Party1] additional bylaws change for your Community Empowerment document
Roelof,
What you describe is the situation in the GAC today, where a single government can object and thereby deny consensus. The GAC presently uses this definition: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”
Indeed, this has occurred during GAC debate on several new gTLD objections, moving some in the GAC to suggest they change to majority voting instead of consensus.
We are considering amending ICANN bylaws so that due deference is reserved for GAC advice that is truly consensus. If we did, let’s understand that the GAC might still send over advice that is supported by many but not a consensus. ICANN would not be obliged to give due deference, but ICANN could still implement the advice if it were supported by the broader community. So I don’t see that good advice would go to waste.
Best, Steve
From: Roelof Meijer Date: Wednesday, February 18, 2015 at 5:59 AM To: Steve DelBianco Cc: "acct-staff@icann.org", "wp1@icann.org" Subject: Re: [Party1] additional bylaws change for your Community Empowerment document
Steve,
I assume you did consider that the option of amending ICANN's bylaws to give due deference only to GAC consensus advice might also work against the public interest, if the advice is in the public interest but not a consensus advice? The amendment introduces the risk of „capture” of GAC advice by a single GAC member
Best,
Roelof
From: Steve DelBianco <sdelbianco@netchoice.org> Date: maandag 16 februari 2015 21:52 To: Jordan Carter <jordan@internetnz.net.nz> Cc: "acct-staff@icann.org" <acct-staff@icann.org>, "wp1@icann.org" < wp1@icann.org> Subject: [Party1] additional bylaws change for your Community Empowerment document
Jordan — while applying a stress test, we discovered a community empowerment measure that was in the Inventory, but wasn’t yet reflected in your Community Empowerment document.
This item could go into the table of Community Powers for Consideration:
Amend ICANN bylaws (Section XI 1j) to give due deference only to GAC consensus advice, and add a definition of “consensus”, such as “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”
This item was prompted by stress test #18 in Category IV, regarding GAC Advice:
18. Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting for advice to ICANN’s board.
Consequence: Under current bylaws, ICANN must consider and respond to GAC advice, even if that advice were not supported by consensus. A majority of governments could thereby approve GAC advice that restricted free online expression, for example.
Existing Accountability Measures:
Current ICANN Bylaws (Section XI) give due deference to GAC advice, including a requirement to try and find “a mutually acceptable solution.”
This is required for any GAC advice, not just for GAC consensus advice.
Today, GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.” But the GAC may at any time change its procedures to use majority voting instead of consensus.
CCWG Proposed Accountability Measures:
One proposed measure is to give the community standing to veto a board decision. If ICANN board acquiesced to GAC advice that was not supported by GAC consensus, the community veto could enable reversal of that decision.
Another proposed measure is to amend ICANN bylaws (Section XI 1j) to give due deference only to GAC consensus advice, and add a definition of “consensus”.
The GAC could change its Operating Principle 47 to use majority voting for formal GAC advice, but ICANN bylaws would require due deference only to advice that had GAC consensus.
Best, Steve — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org <http://www.netchoice.org/> and http://blog.netchoice.org +1.703.615.6206
_______________________________________________ WP1 mailing list WP1@icann.org https://mm.icann.org/mailman/listinfo/wp1
_______________________________________________ Ccwg-accountability3 mailing list Ccwg-accountability3@icann.org https://mm.icann.org/mailman/listinfo/ccwg-accountability3
-- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *Partner* *| IP | Technology | Media | Internet* *666 Third Avenue | New York, NY 10017-5621* *Direct* 212-885-9253 *| **Main* 212-949-9022 *Fax* 212-949-9190 *|* *Cell *917-816-6428 *gsshatan@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com>* *www.lawabel.com <http://www.lawabel.com/>*
participants (3)
-
Avri Doria -
Greg Shatan -
Kavouss Arasteh