[CCWG-ACCT] Responses to Rafael's Questions

Carlos Raúl Gutiérrez G. crg at isoc-cr.org
Fri Feb 5 19:41:53 UTC 2016

Thank you Jorge!

We really have to (re)focus and discuss in a more constructive way.

Carlos Raúl Gutiérrez
+506 8837 7176
Skype: carlos.raulg
On 5 Feb 2016, at 11:40, Jorge.Cancio at bakom.admin.ch wrote:

> Dear Carlos
> Thanks for these points, but ee should not get personal.
> We have come s long way in the ccwg and we have established and 
> settled clear principles of equal participation within the 
> accountability framework.
> And now we are having a specific discussion on the carve-out proposed 
> by Becky, to which we are saying that it is overbroad and should be 
> circumscribed to its original remit (at least how we understood it).
> Let's have a rational and cool debate on these specifics.
> regards
> Jorge
> Von meinem iPhone gesendet
>> Am 05.02.2016 um 20:33 schrieb Carlos Raúl Gutiérrez G. 
>> <crg at isoc-cr.org>:
>> 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

More information about the Accountability-Cross-Community mailing list