Ccwg-accountability3

Download

ccwg-accountability3@icann.org

February 2015

3 participants
2 discussions

Re: [Area 3] [Party2] Doodle Poll and Docs for ACCT WP2
by Kavouss Arasteh Feb. 24, 2015

Feb. 24, 2015

*Dear Becky* *Dear co.chairs* *Dear All,* *On the conference call on 24 Feb Becky casts doubt about the GAC ADV9ICE PERSIAN Gulf string* *She said GAC ADVICE on Persian Gulf .She stated that GAC did not conclude on that SRING * *I wish to reproduce the paragraph 3 from GAC Durban Communique* *Quote * * 3. .date and .persiangulf (ref. Beijing Communiqué 1.c.) **a. The GAC has finalised its consideration of the following strings, and does not object to them proceeding: i. .date (application number 1-1247-30301) * *ii. .persiangulf (application number 1-2128-55439) * *Unquote* I therefore request my respectful Becjy to carefully read that advice with a vir ew to reconsider her position made at thart call conference This should be corrected when minute is appropoved$ I ask Grace and others to incluse the content of this message in the minutes as I did indicate at the meerting Sorry and regret that point was raised . Kavouss 2015-02-24 18:04 GMT+01:00 Paul Rosenzweig < paul.rosenzweig(a)redbranchconsulting.com>: > As I was not at ICANN52, I missed that in the back and forth. I am, of > course, delighted that we get to write the standard!! More power to me! > [That's a joke friends!] > > More seriously, then, if we are to write the standard, we will want to very > carefully define the scopoe of ICANN activity ..... should be interesting > work > P > > Paul Rosenzweig > paul.rosenzweig(a)redbranchconsulting.com > O: +1 (202) 547-0660 > M: +1 (202) 329-9650 > VOIP: +1 (202) 738-1739 > Skype: paul.rosenzweig1066 > Link to my PGP Key > > > -----Original Message----- > From: Burr, Becky [mailto:Becky.Burr@neustar.biz] > Sent: Tuesday, February 24, 2015 11:37 AM > To: Malcolm Hutty; Paul Rosenzweig; wp2(a)icann.org > Cc: 'Thomas Rickert' > Subject: Re: [Party2] Doodle Poll and Docs for ACCT WP2 > > With respect to our task, Jordan and I have chatted and agreed that the > standard falls into our work stream > > > J. Beckwith Burr > Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer > 1775 Pennsylvania Avenue NW, Washington, DC 20006 > Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / > becky.burr(a)neustar.biz > / www.neustar.biz > > > > > > > On 2/24/15, 11:34 AM, "Malcolm Hutty" <malcolm(a)linx.net> wrote: > > > > > > >On 24/02/2015 15:24, Paul Rosenzweig wrote: > >> Colleagues > >> > >> > >> > >> Let me get this started with a very simple statement of four > >> principles that I think must be incorporated in any > >> redress/accountability proposal > > > >Paul, > > > >Thank you for kicking the discussion off with from such a thoughtful > >starting point. > > > >It prompts some immediate reactions on my part. > > > > > >> First, a standard is essential. That is the limiting function that > >> defines what it is that ICANN and/or the Board may do and what, in > >> turn, they may not do. > > > >I agree, and saw the presentation from Becky at ICANN52 as starting > >that discussion very helpfully. I was therefore rather surprised to see > >you write this: > > > >> I suspect that the actual content of that standard is not for WP2 to > >> determine (for myself I want it as narrow as possible). > >> That standard will come from elsewhere (WP1, CCWG, or CWG) as those > >> processes move forward. > > > >From Becky's presentation, I had understood that this WP2 would > >absolutely be considering the standard. If that's not the case, I think > >we need to flag up to the Co-Chairs the need for urgent clarification > >of where this discussion ought to take place - perhaps a WP3 > >specifically on that question? > > > >I think we can rule out CWG-Stewardship; they have explicitly ruled > >most of this out of scope for their group. > > > >> Our task is to insure that a) such standards are formulated; and b) > >> that they are formulated in a manner that is capable of that > >> adjudication. Our input should be to make the terms of the standard > >> as well-defined as drafters are capable of. > > > >Agree. > > > >> > >> > >> Second, our biggest difficulty, in my judgment, will be in defining > >> who is an ³affected party.² As we have seen in the broader debate > >> over ³public interest² in some sense everyone in the world is an > affected > >> party. That, of course, is untenable. We need to give some definition > >> as to who has ³standing² (that¹s an American legal phrase reflecting > >> who may bring a suit) to initiate a complaint. My instinct is to > >> allow it to be a) both directly affected parties that is people > >> with contracts and/or commercial interests in the IANA function; and > >> b) certain representative organizations can reflect the broader > >> interests of certain constituencies. These may or may not be the > >> existing SO/AC types. An area I think needs some real consideration > > > >I disagree with your claim that it is untenable to grant standing to > >any party materially affected by an ICANN decision or action. > > > >I also don't believe it is at all acceptable to limit standing to > >contracted parties: that is one of the major flaws in the existing IRP > >provisions that needs to be corrected. Non-contracted parties have > >legitimate interests too. For example, inasmuch as non-contracted > >parties are consulted by ICANN in its decision-making and policy > >formulation, they equally have an interest in ICANN following its own > >procedures and bylaws. For another, I believe you and I share the view > >that a major concern is the possibilibility of scope creep by ICANN > >resulting in a negative impact other parties' interests without any > >legitimate authority to do so: non-contracted parties (and especially, > >registrants) are absolutely as interested in that as contracted ones. > > > >Let me give you a scenario. Suppose that ICANN deciding that fishing > >was > >bad: fish stocks are heavily depleted and fishing is harming the > >environment and leading to species extinction. In support of that view, > >ICANN consensus policy determines that no domains should be registered > >that promoted fishing or the consumption of fish. This policy would be > >enforced throughout all gTLDs via the RAA; any end-user domain found in > >violation of this policy was subject to immediate cancellation. > >In such a circumstance, I would expect that any individual fisherman > >ought to be able to challenge the policy on the grounds that (i) the > >policy seeks to extend ICANN's control of gTLD policy to regulate an > >unrelated activity, namely fishing, and so was outside ICANN's proper > >scope and void and (ii) as a fisherman, he was materially affected by > >the inability to register a domain in support of his business, and so > >had proper standing to bring such a complaint. Such a fisherman ought > >not to be told that ICANN accountability measures are unavailable to > >him, or that in order to access them he must first obtain the support > >of an ICANN constituency. He has a legitimate complaint, and should be > >heard in his own right. > > > >I would suggest that the main requirements underlying the fear of > >"untenability" to which you refer are really the need to prevent ICANN > >being stymied by frivolous or vexatious objections, or be forced to > >perpetually re-litigate issues that have already been adequately > >reviewed. Limiting standing is at best an indirect way of addressing > >these issues, and one that risks leaving ICANN unaccountable to those > >materially impacted by its policies. Surely these concerns could be > >addressed directly? > > > >That doesn't mean that I would remove any requirement for standing[*]. > >I wouldn't say that my fisherman is materially impacted by the outcome > >in .wine, say, or in domain tasting rules. But a competent tribunal > >ought to be able to determine on the facts and circumstances whether a > >party is materially affected by the outcome of a dispute; courts and > >arbitrators apply this and related standards in other fields all the time. > > > >We can, of course, have a discussion about where to set the threshold > >for standing too: "materially affected by" is higher than "a legitimate > >interest in", but lower than "would suffer serious harm from", for > >example. > > > >[ * or rather, I would keep some test of standing for individuals. I > >don't think I would for ICANN community components: the GAC, or the > >GNSO, or perhaps even any ICANN constituency should automatically have > >standing to trigger a review process in (many/most/all?) matters, > >without need to demonstrate harm or loss. But maybe that is a WP1 > >matter.] > > > >> Third, the binding and independent nature of the review is to my mind > >> the non-negotiable bear minimum of accountability a man or a > >> company shall not be a judge in its own case is a principal of the > >> rule of law with a long provenance for good reason! I am less > >> concerned with exactly how this independent review is created and > >> whether it is juridical (e.g. through the California courts) or > >> arbitral (through some international arbitration body). I think it > >> should be funded by ICANN as a certain mandated level that may not be > >> reduced and that its existence and funding need to be in the > >> Bylaws/Contract/Charter in a way that cannot be amended. > > > >I agree on the bare minimum you propose. I doubt that a court process > >is appropriate (as this community will want to create its own > >standards, that may impose more strict requirements on ICANN than the > >ordinary law would on a private company), and anticipate objections > >from members of the community already concerned about US influence; > >such concerns should be mitigated rather than exacerbated, as would be > >the case if we introduce a new role for the California courts. > > > >> Finally, the provision of non Amendment by ICANN is an unfortunate > >> necessity. > > > >Here I think you are overstating it slightly. Some possibility of > >amendment should exist, but it should be through a process that > >requires a high-level of community support, and not a unilateral action > >by the ICANN Board. I would think that establishing a suitable process > >for amendment would be a core issue for WP1. > > > >> Given the way the Board limited the IRP in April 2013 after it lost > >> the .xxx case and given its failure thus far to fully implement the > >> ATRT recommendations, we need to insiste that the redress process > >> both be created and brought into existence before the IANA transition. > > > >I would like to think that a firm commitment would be sufficient, but > >have heard enough about slow-, partial- or non- implementation in > >related areas to have certain misgiving myself. I suggest we leave this > >until last. > > > > > >> > >> > >> As I said, these are my initial thoughts, more as the way of > >> jump-starting the conversation than as a final ending point. > >> > >> > >> > >> Cheers > >> > >> Paul > >> > >> > >> > >> Paul Rosenzweig > >> > >> paul.rosenzweig(a)redbranchconsulting.com > >> <mailto:paul.rosenzweigesq@redbranchconsulting.com> > >> > >> O: +1 (202) 547-0660 > >> > >> M: +1 (202) 329-9650 > >> > >> VOIP: +1 (202) 738-1739 > >> > >> Skype: paul.rosenzweig1066 > >> > >> Link to my PGP Key > >> > >><https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redbranchcons > >>ult > >>ing.com_index.php-3Foption-3Dcom-5Fcontent-26view-3Darticle-26id-3D19- > >>26I > >>temid-3D9&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8Tj > >>Dmr > >>xdYahOP8WDDkMr4k&m=Ig2519ehwmCW6CCqBz_qY84N3tgA2fLF2pwu7iEQulw&s=mrTS5 > >>2Xl BxoOzv9FePHqO2e0VXIw1TNeDW6VzDZHpeg&e= > > >> > >> > >><https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rsaconference > >>.co > >>m_events_us15_register-3Futm-5Fsource-3Dinhouse-26utm-5Fmedium-3Demail > >>-26 > >>utm-5Fcampaign-3Dsignature-2Dus2015&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw& > >>r=6 > >>2cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=Ig2519ehwmCW6CCqBz_qY84N3 > >>tgA 2fLF2pwu7iEQulw&s=3_yGh8BlWKoW4rX2JIj9ldmhxj-MJ81-HBN2c07JmLc&e= > > >> > >> > >> > >> *From:*Burr, Becky [mailto:Becky.Burr@neustar.biz] > >> *Sent:* Monday, February 23, 2015 8:20 PM > >> *To:* wp2(a)icann.org > >> *Cc:* Thomas Rickert > >> *Subject:* [Party2] Doodle Poll and Docs for ACCT WP2 > >> > >> > >> > >> Hello WP2- > >> > >> > >> > >> Apologies for the slow start, but I¹ve now cleared the decks to focus > >> on this project. > >> > >> > >> > >> You should have received a link to the Doodle Poll to schedule calls > >>for this working party. If you did not, please use > >> this: > >>https://urldefense.proofpoint.com/v2/url?u=https-3A__doodle.com_htxbr2 > >>inp > >>curzi4k&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDm > >>rxd > >>YahOP8WDDkMr4k&m=Ig2519ehwmCW6CCqBz_qY84N3tgA2fLF2pwu7iEQulw&s=jVSWyY_ > >>f67 > >>Bqk_ozavS7_Ue4miAp9sJAW2OSkeFnYmM&e= > >> > >> > >> > >> I¹ve attached a revised Scope document that reflects the work of WP1 > >> to date to attempt to clarify the division of labor. I¹ve also > >> attached a draft working plan, and the power point previously > >> circulated on a ³standard² for ICANN. Jordan and I will chat, but > >> the location for this work is not entirely clear to me. > >> > >> > >> > >> Thanks, > >> > >> Becky > >> > >> > >> > >> > >> > >> J. Beckwith Burr > >> > >> *Neustar, Inc. /* Deputy General Counsel and Chief Privacy Officer > >> > >> 1775 Pennsylvania Avenue NW, Washington, DC 20006 > >> > >> Office: + 1.202.533.2932 Mobile: > >> +1.202.352.6367 / becky.burr(a)neustar.biz > >> <mailto:becky.burr@neustar.biz> / www.neustar.biz > >><http://www.neustar.biz> > >> > >> > >> > >> _______________________________________________ > >> WP2 mailing list > >> WP2(a)icann.org > >> > >>https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mail > >>man > >>_listinfo_wp2&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8M > >>o8T > >>jDmrxdYahOP8WDDkMr4k&m=Ig2519ehwmCW6CCqBz_qY84N3tgA2fLF2pwu7iEQulw&s=I > >>O9e C34-YCvh0NIDb_ao6S1Lt-LFHdFVocQ7_6duViQ&e= > >> > > > >-- > > Malcolm Hutty | tel: +44 20 7645 3523 > > Head of Public Affairs | Read the LINX Public Affairs blog London > >Internet Exchange | > >https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx. > >net > >_&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahO > >P8W > >DDkMr4k&m=Ig2519ehwmCW6CCqBz_qY84N3tgA2fLF2pwu7iEQulw&s=b8T6PTwgtz6eNSv > >OUX > >0hSMqSbxro10_Xffc_n1_1RbI&e= > > > > London Internet Exchange Ltd > > 21-27 St Thomas Street, London SE1 9RY > > > > Company Registered in England No. 3137929 > > Trinity Court, Trinity Street, Peterborough PE1 1DA > > > > > > > _______________________________________________ > WP2 mailing list > WP2(a)icann.org > https://mm.icann.org/mailman/listinfo/wp2 >

1 0

Re: [Area 3] [Party1] additional bylaws change for your Community Empowerment document
by Kavouss Arasteh Feb. 18, 2015

Feb. 18, 2015

Dear All, Please carefully consider what we are proposing, Please be prudent and do not hurry up to change one of the most critical, delicate and vital issue changing b" Consensus" tp " Majority" This is a GAC issue and you need to clearly and specifically seek formal opinion of GAC. Regards Kavouss 2015-02-18 13:03 GMT+01:00 Roelof Meijer <Roelof.Meijer(a)sidn.nl>: > Steve, > > "What you describe is the situation in the GAC today”.. Exactly, but the > GAC can still provide (non-consensus) advice that ICANN must consider and > respond to. > With the suggested amendment we risk getting into a situation, that can > only be broken by the alternative: giving the community standing to veto > a board decision: > > example stress test: > > - The GAC provides sound (in the public interest) but non-consensus > advice on an important matter; > - The ICANN board, referring to the (now amended) bylaws decides not > to consider nor to respond to the advice, and /or uses the fact that the > GAC has no consensus on its position, to take a decision on the matter that > is contrary to the GAC advice; > - Community veto needed to remedy > > > So in the end I wonder if the bylaws amendment and community veto are > alternatives, as it would seem that with the bylaw amendment we still need > community veto in „opposite” situations (good GAC advice vs bad > GAC advice). If that is true, we might as well forget about the amendment > > Cheers, > > Roelof > > From: Steve DelBianco <sdelbianco(a)netchoice.org> > Date: woensdag 18 februari 2015 12:09 > To: Roelof Meijer <roelof.meijer(a)sidn.nl> > Cc: "acct-staff(a)icann.org" <acct-staff(a)icann.org>, "wp1(a)icann.org" < > wp1(a)icann.org> > Subject: Re: [Party1] additional bylaws change for your Community > Empowerment document > > Roelof, > > What you describe is the situation in the GAC today, where a single > government can object and thereby deny consensus. The GAC presently uses > this definition: “consensus is understood to mean the practice of adopting > decisions by general agreement in the absence of any formal objection.” > > Indeed, this has occurred during GAC debate on several new gTLD > objections, moving some in the GAC to suggest they change to majority > voting instead of consensus. > > We are considering amending ICANN bylaws so that due deference is > reserved for GAC advice that is truly consensus. If we did, let’s > understand that the GAC might still send over advice that is supported by > many but not a consensus. ICANN would not be obliged to give due > deference, but ICANN could still implement the advice if it were supported > by the broader community. So I don’t see that good advice would go to > waste. > > Best, > Steve > > > > > > From: Roelof Meijer > Date: Wednesday, February 18, 2015 at 5:59 AM > To: Steve DelBianco > Cc: "acct-staff(a)icann.org", "wp1(a)icann.org" > Subject: Re: [Party1] additional bylaws change for your Community > Empowerment document > > Steve, > > I assume you did consider that the option of amending ICANN's bylaws to > give due deference only to GAC consensus advice might also work against the > public interest, if the advice is in the public interest but not a > consensus advice? The amendment introduces the risk of „capture” of GAC > advice by a single GAC member > > Best, > > Roelof > > From: Steve DelBianco <sdelbianco(a)netchoice.org> > Date: maandag 16 februari 2015 21:52 > To: Jordan Carter <jordan(a)internetnz.net.nz> > Cc: "acct-staff(a)icann.org" <acct-staff(a)icann.org>, "wp1(a)icann.org" < > wp1(a)icann.org> > Subject: [Party1] additional bylaws change for your Community Empowerment > document > > Jordan — while applying a stress test, we discovered a community > empowerment measure that was in the Inventory, but wasn’t yet reflected in > your Community Empowerment document. > > This item could go into the table of Community Powers for Consideration: > > Amend ICANN bylaws (Section XI 1j) to give due deference only to GAC > consensus advice, and add a definition of “consensus”, such as “consensus > is understood to mean the practice of adopting decisions by general > agreement in the absence of any formal objection.” > > This item was prompted by stress test #18 in Category IV, regarding GAC > Advice: > > > 18. Governments in ICANN’s Government Advisory Committee (GAC) amend > their operating procedures to change from consensus decisions to majority > voting for advice to ICANN’s board. > > Consequence: Under current bylaws, ICANN must consider and respond to > GAC advice, even if that advice were not supported by consensus. A majority > of governments could thereby approve GAC advice that restricted free online > expression, for example. > > > Existing Accountability Measures: > > Current ICANN Bylaws (Section XI) give due deference to GAC advice, > including a requirement to try and find “a mutually acceptable solution.” > > This is required for any GAC advice, not just for GAC consensus advice. > > Today, GAC adopts formal advice according to its Operating Principle 47: > “consensus is understood to mean the practice of adopting decisions by > general agreement in the absence of any formal objection.” But the GAC > may at any time change its procedures to use majority voting instead of > consensus. > > > CCWG Proposed Accountability Measures: > > One proposed measure is to give the community standing to veto a board > decision. If ICANN board acquiesced to GAC advice that was not supported > by GAC consensus, the community veto could enable reversal of that decision. > > Another proposed measure is to amend ICANN bylaws (Section XI 1j) to > give due deference only to GAC consensus advice, and add a definition of > “consensus”. > > The GAC could change its Operating Principle 47 to use majority voting > for formal GAC advice, but ICANN bylaws would require due deference only to > advice that had GAC consensus. > > > > > > Best, > Steve > — > Steve DelBianco > Executive Director > NetChoice > http://www.NetChoice.org <http://www.netchoice.org/> and > http://blog.netchoice.org > +1.703.615.6206 > > > > _______________________________________________ > WP1 mailing list > WP1(a)icann.org > https://mm.icann.org/mailman/listinfo/wp1 > >

3 2