[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.
https://www.avast.com/antivirus
-------------- 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