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

Fri Apr 8 11:26:37 UTC 2016

Mark
It is good that you replied to one of the small angle of the famous carve
out
However, all GAC members were expected  seriously consider my proposal as
sent to GAC list re not going to the heavy and rigoureous drafting for
inclusion many many improbable cases in the Bylaws but just cut and paste
the texts as contained in Recs. 1 &2
Pls reply
KAVOUSS

2016-04-08 13:04 GMT+02:00 Mark Carvell <mark.carvell at culture.gov.uk>:

> Dear Jorge
>
> I think this serves to underline that in the new era of transversal
> working with the GNSO in particular, the so-called "carve-out" from a
> community escalation decision in instances where the Board decision would
> be based solely on GAC advice, would be an extremely rare occurrence. Plus
> of course the GAC would be advising the community throughout such a
> decision stage: as has been made clear in the CCWG discussions several
> times, while not being able to exercise a vote due to the carve-out,
> governments would not be excluded from this process.
>
> Kind regards
>
> Mark
>
> Mark Carvell
> Global Internet Governance Policy
> Department for Culture, Media and Sport
> mark.carvell at culture.gov.uk
> tel +44 (0) 20 7211 6062
>
> On 8 April 2016 at 08:54, Kavouss Arasteh <kavouss.arasteh at gmail.com>
> wrote:
>
>> 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
>> <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
>> <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
>>
>>
>> _______________________________________________
>> 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/9fa3b5a9/attachment-0001.html>