[CCWG-ACCT] Responses to Rafael's Questions

Kavouss Arasteh kavouss.arasteh at gmail.com
Sat Feb 6 08:27:48 UTC 2016

Dear Co-Chairs

Dear Beckie

Deal All,

We have noted relatively extensive exchange of e-mails among colleagues
during the last one and half day ; after our devoted call on Recs. 1 and 11

Views are sometime so strong that potentially may give rise to something
that none of us expect.

As merely a CCWG participant ( all of my interventions and message have
been in that capacity only) I WARN ourselves that:

1. We SHALL NOT escalate the issue to end with VOTING, an element that I
personally AGINST that.

2. We m shall not ignore views of GAC nor that of GNSO at all

3. There are difficulties raised by some GAC members mostly in regard with
carve-out concept.

4.Some GAC Member could consider the initial proposal of Beckie, even if
Beckie stated that her initial and subsequent proposal are exactly the same
but that view is not shared, at least , by some GAC members.

5. The show of hand on the Devoted call was not  a VOTE at all on the
substance of the matter but rather whether the participants were ready to
take the proposed compromised text to their constituencies.

6. We need to hear the responses of those constituencies ,probably and
hopefully on Monday’s call

7. Beckie as the author of her creative solution is sincerely asked or
perhaps urged to review her initial and revised proposal again

8.Should we make the text of Beckie  compromise  better to be acceptable
,so far so good.

9.Should that failed WITHOUT GOPING TO VOTE, we need to look at other
possibilities .There are other ways to proceed but let us stop at this
stage and encourage ebvery body to pronounce his or her views on the matter.

10. No matter what option would taken NO VOTING AT ALL-

2016-02-05 23:05 GMT+01:00 Paul Rosenzweig <
paul.rosenzweig at redbranchconsulting.com>:

> And then there were four ….
> Paul Rosenzweig
> paul.rosenzweig at redbranchconsulting.com
> <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:* Olga Cavalli [mailto:olgacavalli at gmail.com]
> *Sent:* Friday, February 5, 2016 3:01 PM
> *To:* Carlos Raúl Gutiérrez G. <crg at isoc-cr.org>
> *Cc:* Accountability Community <accountability-cross-community at icann.org>
> *Subject:* Re: [CCWG-ACCT] Responses to Rafael's Questions
> Dear Carlos,
> Colleagues from Spain and Switzerland are not alone and several members of
> the GAC share the same concerns as they have expressed in this list and
> which Argentina also shares.
> So could you be so kind to clarify your comment "To the colleagues from
> Spain and Switzerland I beg to take a step back".
> Regards
> Olga
> 2016-02-05 16:10 GMT-03:00 Carlos Raúl Gutiérrez G. <crg at isoc-cr.org>:
> Thank you Becky for putting the proposals in the proper context!!
> To the colleagues from Spain and Switzerland I beg to take a step back,
> look at the whole picture and try to think as comprehensibly as Becky has
> just done.
> Best regards
> Carlos Raúl Gutiérrez
> +506 8837 7176
> Skype: carlos.raulg
> On 5 Feb 2016, at 10:03, Burr, Becky wrote:
> 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-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
> _______________________________________________
> 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/92487c9d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2849 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160206/92487c9d/image001-0001.png>

More information about the Accountability-Cross-Community mailing list