[CCWG-ACCT] Responses to Rafael's Questions

Matthew Shears mshears at cdt.org
Fri Feb 5 19:04:01 UTC 2016

+ 1

Thanks Becky.  It really is time to agree this and move on.

On 05/02/2016 10:34, Paul Rosenzweig wrote:
> Information Security Program Charter
> Very much +1.  Well said Becky.
> P
> Paul Rosenzweig
> paul.rosenzweig at redbranchconsulting.com 
> <mailto:paul.rosenzweigesq at redbranchconsulting.com>
> O: +1 (202) 547-0660
> M: +1 (202) 329-9650
> VOIP: +1 (202) 738-1739
> Skype: paul.rosenzweig1066
> Link to my PGP Key 
> <http://www.redbranchconsulting.com/index.php?option=com_content&view=article&id=19&Itemid=9>
> <http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=email&utm_campaign=speakers-us2016>
> *From:*Burr, Becky [mailto:Becky.Burr at neustar.biz]
> *Sent:* Friday, February 5, 2016 1:03 PM
> *To:* Accountability Community <accountability-cross-community at icann.org>
> *Subject:* [CCWG-ACCT] Responses to Rafael's Questions
> Iam 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-en.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


Matthew Shears | Director, Global Internet Policy & Human Rights Project
Center for Democracy & Technology | cdt.org
E: mshears at cdt.org | T: +44.771.247.2987

CDT's Annual Dinner, Tech Prom, is April 6, 2016. Don't miss out - register at cdt.org/annual-dinner.

This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160205/38435f63/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2849 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160205/38435f63/attachment-0001.png>

More information about the Accountability-Cross-Community mailing list