[CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board?
Eric Brunner-Williams
ebw at abenaki.wabanaki.net
Sun Dec 20 00:57:49 UTC 2015
Of necessity, the "decided lack of expertise about DNS" offered as a
description of the GAC and "a very simple example" offered concerning
reserved identifiers, which would include two-alpha (iso3166-1)
sequences (of length two), would also apply to one-alpha sequences (of
length 1), for which members of the Technical Liaison Group, who may
also suffer from a "decided lack of expertise about DNS", went on record
expressing concern.
Eric Brunner-Williams
Eugene, Oregon
On 12/19/15 4:14 PM, Mueller, Milton L wrote:
>
> Mark
>
> Thanks for a strong and quite explicit statement about why you think
> policy making in ICANN should be dominated by governments. Let me
> comment on the claim that the GAC is composed of “public policy
> experts” and that ICANN should therefore show deference to its advice.
>
> Having worked in the GNSO for many years, one of the key frustrations
> policy makers within that SO always have is that the GAC
> members’policy advice more often than not suffers from a decided lack
> of expertise about DNS and about the impact of their advice on actual
> users and suppliers of DNS. To provide a very simple example, certain
> GAC claims about how to protect geographic or international
> organization names showed a fairly woeful lack of expertise about the
> practical implications of their demands on registries, a total lack of
> concern about the rights of many individual internet users of DNS, and
> a complete innocence about relevant international laws. For the most
> part I see governments advancing claims based on political demands of
> certain groups rather than on any special expertise.
>
> This is not to say that governments don’t raise significant and
> legitimate concerns. They often do. The point, however, is that these
> concerns are developed in a narrow, all-government silo without the
> participation and consensus of many of the affected stakeholders. If
> governments want their input to have the same legitimacy as that of
> the GNSO, they really ought to participate directly in the GNSO and be
> subject to the discipline of interacting at all times with all
> relevant stakeholders and developing consensus among them.
>
> And I would say that within the GNSO there are experienced lawyers,
> policy analysts, economists, who often have more expertise in the area
> than your average GAC member. The claim that GAC represents the
> consensus views of 155 governments is pretty wild; all of us have
> watched GAC meetings and we know that only about 60-70 governments
> actually attend any given ICANN meeting and only a dozen actively
> participate. If you really believe that GAC is a global legislator,
> then it ought to be relatively easy for you to get high-level
> representatives from these 155 governments in a room and negotiate a
> binding international treaty, which would be subject to the discipline
> of ratification by your national legislatures. Somehow that never
> seems to happen. Seems GAC wants to have it both ways: global
> legislative power without any of the democratic checks and balances
> and without even directly reaching consensus with the affected
> stakeholders. If you’re wondering why there’s a lot of resistance to
> GAC influence in this process, that’s why. And I know most people
> agree with me but are too intimidated or too diplomatic to say so.
>
> Have a nice holiday
>
> --MM
>
> *From:*accountability-cross-community-bounces at icann.org
> [mailto:accountability-cross-community-bounces at icann.org] *On Behalf
> Of *Mark Carvell
> *Sent:* Friday, December 18, 2015 1:58 PM
> *To:* Phil Corwin <psc at vlaw-dc.com>
> *Cc:* accountability-cross-community at icann.org
> *Subject:* Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw
> create a new "mandatory voting requirement" for the ICANN Board?
>
> Dear Phil and Greg
>
> Man of your concerns are familiar of course from last year's
> consultation on proposed bylaw changes following the joint Board and
> GAC "BGRI" discussions and agreement on how to implement the ATRT2
> recommendations relating to the status of GAC advice and related
> procedures.
>
> Such is the extent now - much more so than in the first 15 years of
> ICANN - of meaningful interaction between the public policy experts on
> the GAC and the non-governmental stakeholders directly engaged in
> developing ICANN policy (witness the GAC-GNSO Consultation Group), as
> well as between the Board and the GAC thanks largely to implementation
> of the recommendations of both ATRT reviews, thankfully we can expect
> substantial rejection of GAC advice by the Board to be an extremely
> rare occurrence.
>
> I would underline in this context that substantial rejection of the
> advice of such a large number of governments (GAC membership is now
> 155) acting in concert to safeguard the global public interest and
> ensure consistency with national and international laws, would be a
> major, politically highly contentious step for the Board to take.
> While I can understand stakeholder anxiety about risk of extending the
> role of governments to the detriment of the successfully embedded
> multi-stakeholder model that is ICANN, this is why I would argue it is
> not unreasonable for a decision to reject public policy interest-based
> advice to be accompanied by a higher threshold than simple majority.
> The evaluation of that support for rejection needs to be rigorous and
> a formally instituted and fully accountable voting procedure is the
> most appropriate means for achieving this.
>
> You will recall it was decided in October 2014 to put "on hold" the
> Board's and the GAC's agreement to institute the two thirds threshold
> for rejection in the bylaws - partly because the rationale was not
> well-communicated (and as a consequence an avalanche of objections was
> received) but also because the timing was wrong as IANA stewardship
> transition loomed large. I would argue the timing is as right as it
> will ever be in the context of Stress Test 18 and I welcomed its
> addition to the proposed text developed by the sub-group.
>
> The Board and the GAC have agreed a set procedures consistent with
> ATRT recommendations for ensuring GAC advice does not fall between any
> cracks or hang in limbo. See
> https://www.icann.org/en/system/files/files/atrt-implementation-report-29jan13-en.pdf
> <https://www.icann.org/en/system/files/files/atrt-implementation-report-29jan13-en.pdf> All
> elements of formal GAC advice are tracked on an open register that
> allows the response and follow up to be monitored
> https://gacweb.icann.org/display/GACADV/GAC+Register+of+Advice This
> serves to maximise transparency of whether advice is accepted or
> rejected - and if the latter, of the enactment of the procedure to
> negotiate and determine if a mutually acceptable solution is possible.
> Default to acceptance of advice if the Board does not respond to the
> GAC would not happen.
>
> I hope this is helpful in explaining why I believe the procedure in
> the current formulation of Stress Test 18 should be supported: a) it
> ensures precision, shared understanding and transparency of
> fully-informed Board decisions in these rare cases when rejection is a
> possibility; b) it enables the GAC to fulfil its role and
> responsibilities in respect of safeguarding the global public
> interest; and c) it serves the best interests of the ICANN community.
>
> Kind regards
>
> Mark
>
>
> Mark Carvell
>
> United Kingdom Representative on the Governmental Advisory Committee
> of ICANN
>
> Global Internet Governance Policy
>
> Department for Culture, Media and Sport
>
> mark.carvell at culture.gov.uk <mailto:mark.carvell at culture.gov.uk>
>
> tel +44 (0) 20 7211 6062
>
> On 18 December 2015 at 15:16, Phil Corwin <psc at vlaw-dc.com
> <mailto:psc at vlaw-dc.com>> wrote:
>
> 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 <tel:202-559-8597>/Direct*
>
> *202-559-8750 <tel:202-559-8750>/Fax*
>
> *202-255-6172 <tel:202-255-6172>/cell*
>
> **
>
> *Twitter: @VlawDC*
>
> */"Luck is the residue of design" -- Branch Rickey/*
>
> *From:*accountability-cross-community-bounces at icann.org
> <mailto:accountability-cross-community-bounces at icann.org>
> [mailto:accountability-cross-community-bounces at icann.org
> <mailto:accountability-cross-community-bounces at icann.org>] *On
> Behalf Of *Schaefer, Brett
> *Sent:* Friday, December 18, 2015 9:55 AM
> *To:* Greg Shatan; Alan Greenberg
> *Cc:* accountability-cross-community at icann.org
> <mailto:accountability-cross-community at 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 at icann.org
> <mailto:accountability-cross-community-bounces at icann.org>
> [mailto:accountability-cross-community-bounces at icann.org] *On
> Behalf Of *Greg Shatan
> *Sent:* Friday, December 18, 2015 12:52 AM
> *To:* Alan Greenberg
> *Cc:* accountability-cross-community at icann.org
> <mailto:accountability-cross-community at 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 at mcgill.ca <mailto:alan.greenberg at 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 <tel:202-608-6097>
> heritage.org <http://heritage.org/>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> <mailto:Accountability-Cross-Community at 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.
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> <mailto:Accountability-Cross-Community at icann.org>
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151219/36e126ca/attachment-0001.html>
More information about the Accountability-Cross-Community
mailing list