[Party1] additional bylaws change for your Community Empowerment document

Roelof Meijer Roelof.Meijer at sidn.nl
Wed Feb 18 12:03:10 UTC 2015


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<mailto:sdelbianco at netchoice.org>>
Date: woensdag 18 februari 2015 12:09
To: Roelof Meijer <roelof.meijer at sidn.nl<mailto:roelof.meijer at sidn.nl>>
Cc: "acct-staff at icann.org<mailto:acct-staff at icann.org>" <acct-staff at icann.org<mailto:acct-staff at icann.org>>, "wp1 at icann.org<mailto:wp1 at icann.org>" <wp1 at icann.org<mailto: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<mailto:acct-staff at icann.org>", "wp1 at icann.org<mailto: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<mailto:sdelbianco at netchoice.org>>
Date: maandag 16 februari 2015 21:52
To: Jordan Carter <jordan at internetnz.net.nz<mailto:jordan at internetnz.net.nz>>
Cc: "acct-staff at icann.org<mailto:acct-staff at icann.org>" <acct-staff at icann.org<mailto:acct-staff at icann.org>>, "wp1 at icann.org<mailto:wp1 at icann.org>" <wp1 at icann.org<mailto: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<http://blog.netchoice.org/>
+1.703.615.6206


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/wp1/attachments/20150218/d16d2f2c/attachment.html>


More information about the WP1 mailing list