[CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws

Fri Apr 8 07:54:03 UTC 2016

Jorge+1
Kavousd

Sent from my iPhone

> On 8 Apr 2016, at 08:52, <Jorge.Cancio at bakom.admin.ch> <Jorge.Cancio at bakom.admin.ch> wrote:
> 
> Dear all
>  
> Just to reiterate what some of us said in the chat yesterday:
>  
> -          GAC Advice is almost always linked to a community process, and the tendency (and wish) is to increase this
> -          GAC Advice is actually quite frequent (at least three times a year)
> -          There is no basis in the CCWG report for isolating GAC Advice from other inputs from the community, and it would be counter to the multistakeholder fashion we work and/or we are trying to work within ICANN
>  
> Hope this helps
>  
> Regards
>  
> Jorge
>  
> Von: accountability-cross-community-bounces at icann.org [mailto:accountability-cross-community-bounces at icann.org] Im Auftrag von Schaefer, Brett
> Gesendet: Donnerstag, 7. April 2016 16:31
> An: Andrew Sullivan <ajs at anvilwalrusden.com>; accountability-cross-community at icann.org
> Betreff: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
>  
> Thanks Andrew, these are interesting comments.
>  
> I agree on 6 and raised similar concerns in the chat Tuesday.
>  
> On 25, I agree that the problem is lack of clarity. It needs to be clear  when a decision is based on GAC consensus or not.
>  
> Also, there is the danger of wrapping a decision based GAC consensus advice into a larger group of unrelated matters. Intentionally or not, it could force the EC into the undesirable position of (1) not opposing a decision based on GAC consensus advice it does not like or (2) opposing it knowing that the unrelated matters that have broad support will also be blocked with it.
>  
> This is why I suggested echoing Article 25.3 to avoid this dilemma. Article 25.3 states:
>  
> ·         The Board shall not combine an amendment of these Bylaws that was the result of a policy development process of a Supporting Organization (a “PDP Amendment”) with any other amendment.  The Board shall indicate in the applicable Board Notice whether such amendment is a PDP Amendment. 
>  
> Here is the text that I suggested:
>  
> ·         The Board shall not combine a decision based on or consistent with consensus GAC advice with any other decision.  The Board shall indicate in the applicable Board Notice whether such a decision is based on or is consistent with consensus GAC advice. 
>  
> If people have helpful edits, go at it. But I think this would separate – in a helpful way – Board decisions based on GAC consensus advice. I don’t think it would be onerous. Consensus GAC decisions are not all that frequent and, under the amended bylaws, must be indicated as such when sent to the Board.
>  
> If the GAC advice is supported elsewhere in the community this requirement should not be problematic because broadly supported advice would not pass thresholds for EC escalation. But it would allow the EC to consider and, if desired, address decisions based on GAC consensus advice in a targeted manner.
>  
> As mentioned in the chat, this in no way is an extension of the GAC carve-out. It would just help clarify when it might apply.
>  
> Best,
>  
> Brett
>  
> Brett Schaefer
> Jay Kingham Senior Research Fellow in International Regulatory Affairs
> Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy
> The Heritage Foundation
> 214 Massachusetts Avenue, NE
> Washington, DC 20002
> 202-608-6097
> heritage.org
> From: accountability-cross-community-bounces at icann.org [mailto:accountability-cross-community-bounces at icann.org] On Behalf Of Andrew Sullivan
> Sent: Thursday, April 07, 2016 9:48 AM
> To: accountability-cross-community at icann.org
> Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
>  
> Dear colleagues,
> 
> Many apologies for missing calls this week, but as I noted in
> Marrakesh this week is the IETF meeting and I have approximately no
> time.
> 
> Anyway, I have some remarks. I'm sorry these are lengthy.
> 
> Q1
> 
> On the Mission, q1, I think it is extremely unfortunate to agree to
> remove the restriction of "in the root zone".
> 
> I reject unequivocally the argument, "It is not true that ICANN
> coordinates assignment ONLY in the root zone, as such term is
> currently understood. ICANN’s gTLD registry and registrar agreements
> and policies deal substantially and primarily with issues relating to
> assignment of names at the second (and in some cases lower) levels of
> the DNS." ICANN's gTLD registry and registrar agreements an policies
> deal susbtantially and primarily with how _those registries and
> registrars_ coordinate assignment in zones outside the root zone.
> That is, ICANN's agreements are a meta-requirement on how other people
> do co-ordination in the DNS, and do not actualy perform the
> co-ordination
> 
> I know that this seems like a fine distinction. But it's important to
> keep it in mind because the language that have been in the bylaws
> historically, and that the CCWG has agreed to restore, is the very
> basis on which various people around the Internet mistake ICANN for
> the Internet Police. By removing the restriction to the root zone, we
> are once again freeing ICANN to assert control down the DNS -- a
> control that is very much inconsistent with the distributed authority
> design of the DNS. 
> 
> Q3
> 
> It might be worth observing also that, since the requester is the
> person who asked for the transcripts and recordings, presumably the
> requester could be asked about certain redactions due to the issues
> outlined.
> 
> Q6
> 
> The proposal for the community just to endorse whatever the board
> decides here strikes me as potentially risky. Supposed the community
> replaces a recalled board member with a new one that is less
> accommodating of a prevailing majority of the Board. The Board would
> be able to remove that new director with a 75% majority. If the EC
> does not have the ability to reject the Board's decision to remove,
> then there could be a procedural deadlock that could only be
> ameliorated by a complete replacement of the Board. That seems
> undesirable.
> 
> Q17
> 
> I believe the requested addition is overspecification. It will simply
> yield disputes about whether a given recommendation is limited in the
> relevant way.
> 
> Q25
> 
> The document says
> 
> Initially, “solely” was added to tie the Petition Notice to the
> GAC Consensus Board Resolution. For example, the ICANN Budget is
> an amalgamation of many different inputs. If a particular
> expenditure is tangentially related to GAC advice, then the GAC
> should not be removed from voting on that petition.
> 
> I don't understand this argument. There are two possibilities: either
> the expenditure is solely related to GAC advice (in which case,
> whether it's "tangential" is irrelevant) or it is not. If it is not,
> then the GAC exclusion is not entailed. If it is solely related to
> GAC advice, then I don't get the claim above that the GAC should not
> be excluded -- that's the whole point of the "carve out".
> 
> I hope these remarks are useful. Please see also the remarks that I sent in collaboration with my colleagues on the IAB.
> 
> Best regards,
> 
> A
> 
> 
> 
> On Wed, Apr 06, 2016 at 06:30:14PM -0400, Bernard Turcotte wrote:
> > All,
> > 
> > Co-chairs and rapporteurs have reviewed and proposed answers to all
> > questions some based on the results of the Tuesday April 5th meeting of the
> > CCWG-Accountability.
> > 
> > These are attached in preparation for the Thursday April 7th meeting of the
> > CCWG-Accountability on this topic.
> > 
> > The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
> 
> 
> > _______________________________________________
> > Accountability-Cross-Community mailing list
> > Accountability-Cross-Community at icann.org
> > https://mm.icann.org/mailman/listinfo/accountability-cross-community
> 
> 
> -- 
> Andrew Sullivan
> ajs at anvilwalrusden.com
> _______________________________________________
> 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/20160408/2c5bacf1/attachment-0001.html>