[CCWG-ACCT] Responses to Rafael's Questions

James M. Bladel jbladel at godaddy.com
Sat Feb 6 17:47:43 UTC 2016


Given the very different roles & natures of SO¹s versus ACs, this
comparison of voting thresholds doesn¹t make sense.

J.


On 2/6/16, 4:29 , "accountability-cross-community-bounces at icann.org on
behalf of Perez Galindo, Rafael"
<accountability-cross-community-bounces at icann.org on behalf of
RPEREZGA at minetur.es> wrote:

>Dear Becky,
>
>Your proposal establishes that there are situations where the GAC would
>be excluded from participating in specific considerations, since it is
>³unique² in its capacity to compel the Board to negociate, even if at the
>end the Board is free to make their decision.
>
>I kindly ask for clarification on the ³uniqueness² of the GAC, since
>ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the
>board needs a 2/3 majority to go against the GNSO recommendation approved
>by supermajority AND that the Board shall engage in a ³discussion² with
>the Council (letters c and d), that could end up again with another
>voting from the Board to reject the new GNSO recommendation by 2/3.
>
>In the same vein, as regards Annex B and the ccNSO PDP, the Board and the
>Council shall discuss ³in good faith and in a timely and efficient
>manner, to find a mutually acceptable solution³.
>
>In conclusion, for the very same reason, namely avoid the ³two bites at
>the apple² situation, it could be argued that if the GAC should be
>singled out to be carved out, the terms for carving out other SO/ACs
>should as well be established.
>
>Looking forward to hearing others' views, and apologies in advance if I
>have misunderstood the processes above described.
>
>Best
>Rafael
>
>
>________________________________________
>From: Perez Galindo, Rafael
>Sent: 05 February 2016 22:31
>To: Burr, Becky; Accountability Community
>Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
>
>Thank you Becky for kindly answering my questions, much appreciated.
>
>I hope to get back to you with further comments as I proceed with
>internal consultations.
>
>I only would like to draw your attention now to the fact that your
>proposal, in its broad scope now clearly defined (and apologies here if
>some of us understood that you were referring to a limited scope), is
>essentially different from the discussions on ST 18 that we all have been
>having during the last year. This addition to the package is not related
>to percentages nor thresholds anymore, nor how the Board may react to GAC
>advice (remember this and only this was the reason why Steve del Bianco
>put forward ST 18!!) , but goes far beyond, as it actually regulates the
>access of the GAC to the EC.
>
>For that reason, I believe it should be very carefully analyzed and
>assessed, from an implementing and legal POV. Such a decision cannot be
>taken in a rush, without considering its consequences and possible side
>effects.
>
>Best
>Rafael
>
>
>Sent from a mobile device. Please excuse any typos.
>-------- Original message --------
>From: "Burr, Becky"
>Date:05/02/2016 19:04 (GMT+01:00)
>To: Accountability Community
>Subject: [CCWG-ACCT] Responses to Rafael's Questions
>
>I am going to attempt to respond to Rafael¹s questions, below.  This is a
>long post, so apologies in advance.
>
>I¹d like to start out by saying that my proposal does not in any way
>prevent the GAC from participating in any community discussion
>whatsoever, or from continuing to provide advice on public policy matters
>whenever and however it chooses.  Rather, the compromise would limit the
>GAC¹s ability to participate as a decision-maker in the very limited
>situation in which the community takes exception to the Board¹s
>implementation of GAC Advice and a community discussion is initiated to
>explore use of a community power to challenge the Board¹s action.  Even
>in those limited situations where the carve out would apply, the GAC is
>still able to participate in discussion, to engage in advocacy, to
>persuade, to issue more advice, etc.  The only impact is that at the end
>of the day the GAC would not count towards the thresholds necessary to
>block or support exercise of the relevant power.  So please, do not say
>that anyone is trying to silence the GAC or to in any way limit its
>current authority.
>
>Rafael¹s questions appear in blue italic below, and my answers follow:
>
>1. We have previously discussed it, but we still fail to understand why
>this ³carve-out² is only applicable to the GAC. If this measure is
>foreseen to avoid the ³two-bites-at-the-apple² situation, for instance
>the GNSO is as well in a position of being ³judge and part² when it comes
>to decisions of the Board based on a PDP. In these cases, the GNSO is
>part (has proposed a policy and the Board has accepted it) and judge
>(through its participation in the EC, it can participate through its vote
>in the rejecting of the challenge to this policy). This situation is
>unfair to the rest of SO/ACs. What are the reasons for such a privilege?
>In this vein, although the GAC has a ³mutually agreeable procedure to TRY
>to find a solution², it CANNOT force the Board to act according to its
>advice, therefore a Board decision based on GAC Advice is as free as a
>Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three
>with a 2/3 threshold for rejection by ICANN Board). Why is the GAC
>singled out then?
>
>I have previously explained this, as have others on the calls and in the
>chat.  My previous response follows.  The fact is that the Board¹s
>obligation to work to try to find a mutually agreeable solution before
>rejecting GAC Advice gives the GAC both a formidable and unique power to
>stop a process in its tracks and compel the Board to negotiate.  The fact
>that in the end a mutually acceptable solution may not be found does not
>change the  nature of that power.  And GAC advice is not constrained in
>any material way ­ it can involve any topic with ³public policy²
>implications, and it can be issued at any time before, during, or after a
>policy development process has concluded, and indeed midway during
>implementation of such policy.  No other SO or AC has that authority.
>The GAC is singled out because it, and it alone, has this authority.
>
>My previous response to this same question from Jorge follows:
>
>Jorge asks why I am drawing a distinction between GAC Advice and the
>output (e.g., a policy developed through a PDP) of a supporting
>organization or this new ³GNSO Guidance." The differences between a PDP
>(or Guidance on implementation of a PDP) and GAC Advice are both
>structural and substantive.   In short, the process for issuing GNSO
>policy and guidance has built-in safeguards to prevent Mission creep and
>promote transparency and public consultation.  For many reasons,
>including some that I consider entirely appropriate, that¹s not the case
>with GAC Advice.
>
>On the one hand, the GAC can give Advice on any topic it likes.  Yes,
>technically it must relate to ³public policy² - but as we know that is a
>very broad concept.  The GAC can also give that Advice at any time it
>likes - before, during, or well after a PDP or even the Board¹s
>acceptance of a PDP.     There is no rule that says that GAC Advice must
>relate to a topic within ICANN¹s Mission or that such Advice must be
>consistent with ICANN¹s Bylaws.  Both the flexibility with respect to
>topic and timing mean that GAC Advice can be disruptive to ongoing policy
>development and/or implementation. And, under Rec. 11 as currently
>proposed, the Board must accept that Advice unless 66% of the Board
>opposes it.  That¹s the case no matter what that Advice is and even if a
>majority of the Board thinks it would violate ICANN¹s Bylaws to implement
>that Advice.
>
>A PDP, on the other hand, takes place in a highly structured environment
>that is strictly controlled both by subject matter and sequencing.  Even
>before the PDP really gets off the ground it is subject to review by
>ICANN¹s General Counsel as to whether or not it is within ICANN¹s
>Mission.  That is a critical structural safeguard against scope creep
>that distinguishes a PDP from GAC Advice.
>
>The PDP process is highly structured, with numerous safeguards that
>protect against scope creep and ensure transparency:
>
>a.  Final Issue Report requested by the Board, the GNSO Council
>("Council") or Advisory Committee. The issue report must affirmatively
>address the following issues:
>€  The proposed issue raised for consideration;
>€  The identity of the party submitting the request for the Issue Report;
>€  How that party is affected by the issue, if known;
>€  Support for the issue to initiate the PDP, if known;
>€  The opinion of the ICANN General Counsel regarding whether the issue
>proposed for consideration within the Policy Development Process is
>properly within the scope of the ICANN's mission, policy process and more
>specifically the role of the GNSO as set forth in the Bylaws.
>€  The opinion of ICANN Staff as to whether the Council should initiate
>the PDP on the issue
>b. Formal initiation of the Policy Development Process by the Council;
>c.  Formation of a Working Group or other designated work method;
>d.  Initial Report produced by a Working Group or other designated work
>method;
>e.  Final Report produced by a Working Group, or other designated work
>method, and forwarded to the Council for deliberation;
>f.  Council approval of PDP Recommendations contained in the Final
>Report, by the required thresholds;
>g.  PDP Recommendations and Final Report shall be forwarded to the Board
>through a Recommendations Report approved by the Council]; and
>h.  Board approval of PDP Recommendations.
>
>
>2. If this ³carve-out² were to be accepted, how would the exclusion of
>the GAC from a community decision-making process be triggered? Who would
>decide on such things? Who would control the legality of such a decision?
>The carve-out refers generically to ³Board decisions² to ³implement GAC
>advice². But we need to bear in mind that Board decisions very often rely
>on many different inputs for any decision (a PDP, advice from advisory
>committees, including the GAC, legal advice, etc.), and rarely only stem
>exclusively from GAC advice. Would this ³carve-out² mean that where there
>is a Board decision based on such multiple sources, only one of them
>being a GAC advice, the GAC would be excluded from any community power
>related to such a Board decision? How do we make sure that if such a
>³carve-out² is accepted it has not these effects, and ONLY applies when
>the Board acts based ONLY on GAC advice?
>
>This seems fairly straightforward.  The GAC keeps a ³scorecard² regarding
>the Board¹s handling of GAC Advice.  GAC Advice is listed and tracked.
>ICANN tracks its responses formally.  See, for example,
>https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-e
>n.pdf.    To the extent that other organizations have provided similar
>advice, they have not had the opportunity to compel the Board to the
>negotiation table with respect to that advice.  In such cases, they could
>still participate in the decision making process in an effort to block
>exercise of a community power challenging the Board¹s implementation of
>GAC Advice if, for example, they happened to agree with that Advice
>and/or thought the way the Board implemented that Advice was appropriate,
>etc.
>
>3. What happens if a Board decision is based on GAC advice which in turn
>is based on international law, relevant national law and/or important
>reasons of public policy? We should remember that under Rec11 GAC will be
>obliged to act under a ³no formal objection rule² (full consensus).
>Should the community be able to overturn such a Board decision without
>giving the possibility to the GAC to intervene in such a process (based
>on a GAC consensus)?
>
>It is not the case now, nor has it ever been the case that the position
>of the GAC will prevail simply because it asserts that its views are
>mandated by international law, relevant national law, and/or important
>reasons of public policy.
>
>Now, and in the future, the Board must make this call in the first
>instance, subject to applicable law and in light of ICANN¹s Mission,
>Commitments & Core Values.  If enough of the community thinks the Board
>got it wrong, it has the right to challenge the Board¹s implementation
>action ­ e.g., by rejecting a proposed Bylaws change, by bringing an IRP,
>or ultimately, by recalling the Board.  Throughout this, the Board, the
>GAC, SOs, other ACs, etc. will have the opportunity to make their
>respective cases.  The thresholds for the exercise of community powers
>have been deliberately set to require broad support.
>
>Let me repeat again what I said at the outset ­ nothing prevents the GAC
>from ³intervening² through debate, discussion, persuasion, advice or any
>other non-decisional role.
>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>
>_______________________________________________
>Accountability-Cross-Community mailing list
>Accountability-Cross-Community at icann.org
>https://mm.icann.org/mailman/listinfo/accountability-cross-community



More information about the Accountability-Cross-Community mailing list