[CCWG-ACCT] Responses to Rafael's Questions

Burr, Becky Becky.Burr at neustar.biz
Fri Feb 5 20:00:16 UTC 2016

I¹ve answered this question several times, but will try once more.

1.  This is not over broad - GAC Advice is uniquely privileged compared to
other input, including PDPs and GNSO Guidance.  The community must be
empowered to challenge the Board¹s implementation of that Advice, and
giving the GAC a decisional role in blocking such a challenge (whether
that is through blocking a bylaw, bringing an IRP, etc.) addresses the two
bites at the apple structural problem.   The same principle applies
whether the challenge is through an IRP or through a vote to reject a
proposed Bylaw.  There is, on the other hand, no principled basis for
limiting this carve out to an IRP.

2.  If you want a sensible discussion, stop claiming that this carve out
would ³exclude" the GAC from community decisions on ³topics² such as
ccTLDs and gTLDs and/or ³community decision making." There is a register
of GAC Advice.  There is a comprehensive report of GAC Advice on new gTLDs
and the Board¹s response.
.pdf.  It seems quite specific to me, and clearly does not begin to cover
the waterfront of new gTLD ³topics.²  The GAC is the master of its own
Advice, and the generality or specificity of such Advice is in the GAC¹s
exclusive control.  And in any case, as someone on the list has already
pointed out, it is up to the GAC to decide whether it wants to issue
formal Advice on a particular topic, whether it would prefer to issue a
compilation of member views (as it has in the past and which does not
constitute Advice) or whether it wants to do something else entirely and
thus preserve your role as a decision-maker.  The bottom line is that the
GAC should not be able to force the Board to the negotiating table on a
specific issue and then participate AS A DECISION MAKER in the exercise of
a community power challenging the Board¹s implementation of the output of
negotiations on that specific issue.

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

On 2/5/16, 2:20 PM, "Jorge.Cancio at bakom.admin.ch"
<Jorge.Cancio at bakom.admin.ch> wrote:

>Dear Carlos 
>We are trying to have a discussion on substance, I feel, and I'm not
>seeing any argument addressing the concern that this "carve out" may be
>As I said before, as there is standing GAC advice on ccTLDs and new
>gTLDs, GAC would be excluded from any community decision related to Board
>decisions on such topics, which leaves little room for GAC participation
>for the GAC in the community mechanism.
>I feel that if we do not return to a sensible discussion, based on
>Becky's original description of the carve-out, this amounts to GAC
>exclusion from any community decision making.
>Something which has no basis in prior agreements, in prior draft reports
>nor in the feedback from chartering organisations and public comment.
>Von meinem iPhone gesendet
>> Am 05.02.2016 um 20:13 schrieb 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
>>> 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
>>> €  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,
>>>gfNIRYKfrLDW_Eng&e= .    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 /
>>> _______________________________________________
>>> Accountability-Cross-Community mailing list
>>> Accountability-Cross-Community at icann.org
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org

More information about the Accountability-Cross-Community mailing list