[CCWG-ACCT] Responses to Rafael's Questions

[Carlos Raúl Gutiérrez G.]

Dear Jorge,

let me repeat my previous (before transition) points concerning the 
issues on the table, as the reason for asking for a wider framework for 
this discussion:

* a clear difference between SOs and ACs remain. While the transition 
discussion is focused on some kind of equal rights for all SO and AC for 
specific accountabiliyt purposes, I still see big differences between 
all of them, internally and externally. So I don’t think that the 
tactic to play a GNSO vs. , while easy to explain to your principals, is 
a particularly productive one in the CCWG.
** we are coming out of a fresh experience of GAC advice to the Board in 
terms of a few new gTLDs that may come back to us, even under the new 
Accountability rules (.africa, .amazon, .wine, etc.). So lets not forget 
that whatever is being discussed may come back to us in the form of new 
responsibilities/liabilities from the previous round.
*** lets not forget the the NTIA assumption is that the USG will step 
back vis a vis the community, but not to create more powers to 
Governments altogether. So it may not be smart to fight for pyrric 
objectives.

So lets cool down and take a fresh approach.

Best regards


Carlos Raúl Gutiérrez
+506 8837 7176
Skype: carlos.raulg
On 5 Feb 2016, at 11:20, 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 overbroad.
>
> 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.
>
> best
>
> Jorge
>
>
> 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 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