[CCWG-ACCT] Responses to Rafael's Questions
Dr Eberhard W Lisse
directors at omadhina.net
Sun Feb 7 13:44:49 UTC 2016
The amendment is accepted :-)-O
el
On 2016-02-07 15:27 , Paul Rosenzweig wrote:
> I agree too, with the friendly amendment that it isn’t the “GAC” that is
> using the tactic, but merely a small minority of vocal GAC members who
> hope we will mistake their opposition for GAC opposition …
>
>
>
> Paul
[...]
>
>
> *From:*Dr Eberhard W Lisse [mailto:epilisse at gmail.com]
> *Sent:* Sunday, February 7, 2016 12:23 AM
> *To:* CCWG Accountability <accountability-cross-community at icann.org>
> *Cc:* Lisse Eberhard <directors at omadhina.NET>
> *Subject:* Re: [CCWG-ACCT] Responses to Rafael's Questions
>
>
>
> I fully agree.
>
>
>
> GAC is an AC, not an SO, but receives deference to consensus advice.
>
>
>
> It obviously wants more influence. But that is not an accountability
> measure that must be in place before the transition can take.
>
>
>
> it does have however have to potential to break the Arasteh/Burr
> Compromise and the Consensus that we seem to have for it.
>
>
>
> It strikes me as the classic tactic from Negotiation 101: "Always ask
> for more" :-)-O
>
> --
>
> Sent from Dr Lisse's iPad mini 4
>
>
> On 7 Feb 2016, at 01:30, Robin Gross <robin at ipjustice.org
> <mailto:robin at ipjustice.org>> wrote:
>
> I think it is worth considering the extent to which providing GAC
> with decisional authority over ICANN’s governance violates ICANN’s
> Articles of Organization and Bylaws, which require it to operate in
> an accountable and transparent way.
>
>
>
> This was certainly a significant issue in the last summer's .africa
> IRP ruling, where the panel found that GAC breached its obligations
> to act transparently and equitably in accordance with ICANN’s
> Articles and Bylaws. The panel found that as a constituent body of
> ICANN, the GAC (and the board) had a legal obligation to act
> transparently and equitably, and they did not, creating a breach of
> ICANN’s Articles and Bylaws.
>
>
>
> What we are doing here is providing this particular constituent body
> of ICANN, which has no transparency requirements nor track record of
> transparency with equal decisional authority in Rec 1 and greater
> decisional authority in Rec 11 than those constituent parts of ICANN
> which are required to act transparently, such as the GNSO. This is
> another fundamental flaw in the proposal.
>
>
>
> Similarly, there is nothing that requires GAC to be “bottom-up” in
> its membership. Democratic and non-democratic governments are
> welcome in the GAC without distinction. Perhaps that was fine when
> GAC was purely advisory, but now that it will be provided decisional
> authority on so-called “equal footing” with those constituent parts
> of ICANN that are required to be operated in a bottom-up and
> democratic manner, it becomes a significant problem and major
> adjustment in the fundamental model of Internet governance, which
> itself becomes less democratic of a model.
>
>
>
> GAC has not even been able to agree that it */wants/* this major
> shift in its role and the change to the multi-stakeholderism
> governance model that comes with it. If it can’t do that, those the
> parts of Recs 1 & 11 that enhance GAC’s power need to go. Otherwise
> ICANN risks violating its own Articles and Bylaws by significantly
> empowering the part of it, which is not required to be transparent,
> accountable, or bottom-up as mandated by these legal instruments.
>
>
>
> Robin
>
>
>
>
>
>
>
> On Feb 6, 2016, at 3:03 PM, Burr, Becky <Becky.Burr at neustar.biz
> <mailto:Becky.Burr at neustar.biz>> wrote:
>
>
>
> Rafael, with all due respect I have explained in great detail
> why a PDP
> and GAC Advice cannot be compared. Here is my explanation again:
> **********************
>
> 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.
>
>
>
> The proposal to create “GNSO Guidance” doesn’t change things
> dramatically
> – as proposed by the Policy and Implementation Working Group,
> because such
> guidance "would typically involve clarification of, or advice on
> existing
> gTLD policy recommendations.”
>
>
>
>
>
>
> 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://neustar.biz>
> <http://www.neustar.biz>
>
>
>
>
> On 2/6/16, 1:39 PM, "Jorge.Cancio at bakom.admin.ch
> <mailto:Jorge.Cancio at bakom.admin.ch>"
> <Jorge.Cancio at bakom.admin.ch
> <mailto:Jorge.Cancio at bakom.admin.ch>> wrote:
>
>
> Dear all
>
> Perhaps we shall remind ourselves that every SO and every AC
> has a
> legitimate role within the development of policies and their
> implementation within ICANN.
>
> And all these roles are different but equally necessary, in
> their
> specific form, for the develpment of such policies and their
> implementation.
>
> Some develop policies and others give advice, all according
> to the
> existing rules of ICANN, which lay out its specific model of
> multistakeholder collaboration.
>
> Our work here in the ccwg has not been, and is not,
> according to our
> charter, to change this model.
>
> We have been tasked, as I have been understanding our work,
> to develop
> new accountability measures, primarily directed to establish
> means for
> the community to check the workings of ICANN as an organization.
>
> And in this new community empowerment framework we have
> agreed from the
> beginning that all SO/AC willing to participate should be
> treated equally
> - that they should have an equal footing.
>
> Any compromise we may find during these last days must be
> consistent with
> this principle, supported repeatedly in public comment periods.
>
> Best
>
> Jorge
>
> Von meinem iPhone gesendet
>
>
> Am 06.02.2016 um 19:06 schrieb James M. Bladel
> <jbladel at godaddy.com <mailto:jbladel at godaddy.com>>:
>
> Given the very different roles & natures of SO¹s versus
> ACs, this
> comparison of voting thresholds doesn¹t make sense.
>
> J.
>
>
> On 2/6/16, 4:29 ,
> "accountability-cross-community-bounces at icann.org
> <mailto:accountability-cross-community-bounces at icann.org> on
> behalf of Perez Galindo, Rafael"
> <accountability-cross-community-bounces at icann.org
> <mailto:accountability-cross-community-bounces at icann.org> on
> behalf of
> RPEREZGA at minetur.es <mailto:RPEREZGA at minetur.es>> wrote:
>
>
> Dear Becky,
>
> Your proposal establishes that there are situations
> where the GAC would
> be excluded from participating in specific
> considerations, since it is
> ³unique² in its capacity to compel the Board to
> negociate, even if at
> the
> end the Board is free to make their decision.
>
> I kindly ask for clarification on the ³uniqueness²
> of the GAC, since
> ICANN Bylaws Annex A Section 9 on GNSO PDP process
> establish that the
> board needs a 2/3 majority to go against the GNSO
> recommendation
> approved
> by supermajority AND that the Board shall engage in
> a ³discussion² with
> the Council (letters c and d), that could end up
> again with another
> voting from the Board to reject the new GNSO
> recommendation by 2/3.
>
> In the same vein, as regards Annex B and the ccNSO
> PDP, the Board and
> the
> Council shall discuss ³in good faith and in a timely
> and efficient
> manner, to find a mutually acceptable solution³.
>
> In conclusion, for the very same reason, namely
> avoid the ³two bites at
> the apple² situation, it could be argued that if the
> GAC should be
> singled out to be carved out, the terms for carving
> out other SO/ACs
> should as well be established.
>
> Looking forward to hearing others' views, and
> apologies in advance if I
> have misunderstood the processes above described.
>
> Best
> Rafael
>
>
> ________________________________________
> From: Perez Galindo, Rafael
> Sent: 05 February 2016 22:31
> To: Burr, Becky; Accountability Community
> Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
>
> Thank you Becky for kindly answering my questions,
> much appreciated.
>
> I hope to get back to you with further comments as I
> proceed with
> internal consultations.
>
> I only would like to draw your attention now to the
> fact that your
> proposal, in its broad scope now clearly defined
> (and apologies here if
> some of us understood that you were referring to a
> limited scope), is
> essentially different from the discussions on ST 18
> that we all have
> been
> having during the last year. This addition to the
> package is not
> related
> to percentages nor thresholds anymore, nor how the
> Board may react to
> GAC
> advice (remember this and only this was the reason
> why Steve del Bianco
> put forward ST 18!!) , but goes far beyond, as it
> actually regulates
> the
> access of the GAC to the EC.
>
> For that reason, I believe it should be very
> carefully analyzed and
> assessed, from an implementing and legal POV. Such a
> decision cannot be
> taken in a rush, without considering its
> consequences and possible side
> effects.
>
> Best
> Rafael
>
>
> Sent from a mobile device. Please excuse any typos.
> -------- Original message --------
> From: "Burr, Becky"
> Date:05/02/2016 19:04 (GMT+01:00)
> To: Accountability Community
> Subject: [CCWG-ACCT] Responses to Rafael's Questions
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_sy
> stem_files_files_gac-2Dadvice-2Dscorecard-2D07oct15-2De&d=CwIF-g&c=MOptN
> lVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn
> 5PbwQ801bKyEaf_KkbWRX6C6Ri6uiICMe-nIA&s=LkCxNJyFaoVIBzQ9JqTXU_fxmDE1Z366
> mOozgyGbT28&e=
> n.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://neustar.biz><http://www.neustar.biz>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> <mailto:Accountability-Cross-Community at icann.org>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma
> n_listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDAL
> C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bK
> yEaf_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUV
> E&e=
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> <mailto:Accountability-Cross-Community at icann.org>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman
> _listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDALC_
> lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bKyEa
> f_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUVE&e=
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> <mailto: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
> <mailto:Accountability-Cross-Community at icann.org>
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
--
Dr. Eberhard W. Lisse 4-5 St Annes Walk, Alderney
<directors at omadhina.net> Guernsey, GY9 3JZ
Omadhina Internet Services Ltd British Channel Islands
More information about the Accountability-Cross-Community
mailing list