[CCWG-ACCT] Responses to Rafael's Questions

Paul Rosenzweig paul.rosenzweig at redbranchconsulting.com
Sun Feb 7 13:27:15 UTC 2016


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

 

Paul Rosenzweig

 <mailto:paul.rosenzweigesq at redbranchconsulting.com> paul.rosenzweig at redbranchconsulting.com 

O: +1 (202) 547-0660

M: +1 (202) 329-9650

VOIP: +1 (202) 738-1739

Skype: paul.rosenzweig1066

 <http://www.redbranchconsulting.com/index.php?option=com_content&view=article&id=19&Itemid=9> Link to my PGP Key

 <http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=email&utm_campaign=speakers-us2016> 

 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160207/cdf86a3c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2849 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160207/cdf86a3c/image001-0001.png>


More information about the Accountability-Cross-Community mailing list