[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