[CCWG-ACCT] Responses to Rafael's Questions

Sat Feb 6 18:08:00 UTC 2016

Of course it doesn't. . As I have said he is being deliberately obtuse. 
--
Paul Rosenzweig
Sent from myMail app for Android Saturday, 06 February 2016, 00:47PM -05:00 from "James M. Bladel" < jbladel at godaddy.com> :

>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
>
>_______________________________________________
>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/20160206/c08dc887/attachment-0001.html>