[CCWG-ACCT] Responses to Rafael's Questions

Dr Eberhard W Lisse epilisse at gmail.com
Sun Feb 7 05:22:49 UTC 2016


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> 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> 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://www.neustar.biz>
>> 
>> 
>> 
>> 
>> On 2/6/16, 1:39 PM, "Jorge.Cancio at bakom.admin.ch"
>> <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>:
>>>> 
>>>> 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 on
>>>> behalf of Perez Galindo, Rafael"
>>>> <accountability-cross-community-bounces at icann.org on behalf of
>>>> 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://www.neustar.biz>
>>>>> _______________________________________________
>>>>> Accountability-Cross-Community mailing list
>>>>> 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
>>>> 
>>>> 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
>> 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/20160207/fe495a25/attachment-0001.html>


More information about the Accountability-Cross-Community mailing list