[Area 3] [Party1] additional bylaws change for your Community Empowerment document
Greg Shatan
gregshatanipc at gmail.com
Wed Feb 18 16:15:46 UTC 2015
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 at 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 at 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 at netchoice.org>
>> Date: woensdag 18 februari 2015 12:09
>> To: Roelof Meijer <roelof.meijer at sidn.nl>
>> Cc: "acct-staff at icann.org" <acct-staff at icann.org>, "wp1 at icann.org" <
>> wp1 at 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 at icann.org", "wp1 at 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 at netchoice.org>
>> Date: maandag 16 februari 2015 21:52
>> To: Jordan Carter <jordan at internetnz.net.nz>
>> Cc: "acct-staff at icann.org" <acct-staff at icann.org>, "wp1 at icann.org" <
>> wp1 at 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 at icann.org
>> https://mm.icann.org/mailman/listinfo/wp1
>>
>>
>
> _______________________________________________
> Ccwg-accountability3 mailing list
> Ccwg-accountability3 at 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 at lawabel.com <gsshatan at lawabel.com>*
*ICANN-related: gregshatanipc at gmail.com <gregshatanipc at gmail.com>*
*www.lawabel.com <http://www.lawabel.com/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ccwg-accountability3/attachments/20150218/c7ae8e12/attachment-0001.html>
More information about the Ccwg-accountability3
mailing list