- Ccwg-accountability3 - lists.icann.org

Re: [Area 3] [CCWG-ACCT] Issues with Providing Public Comments on CCWG-Accountability Proposal
by Kavouss Arasteh Dec. 5, 2015

Dec. 5, 2015

Dear Co-Chair, About 56 message exchanged among CCWG on the issue of the sequence of actions relation who should comment before who? The position of Co-Chairs as responsible for the conduct of the discussion IS NOW URGENTLY required. There are pros and cones. The major deciding element is time Should we wait until public comment period is expired the we formally ask the SIX CHARTERING ORGANIZATION TO COMMENT? However, any member of chartering oerganization uindividually or collectively could comment during this period BUT perhapsd at the end of the period once the results of publéic comments are available we could formalély ask the SIX chartering organization to cooment on each recommenadstion. The advantage of that would be the chartering organization would need to take into account the public comment as a guidance or as background information. We may loose one or two weeks but itworths to do so. PLEASE KINDLY AND EURGENTLY CONSIDER THE MATTER and if required organize a confrence call within a week Regards Kavouss

1 0

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

Fwd: [CCWG-ACCT] got some lawyerly answers on membership structure
by Kavouss Arasteh Jan. 28, 2015

Jan. 28, 2015

Dear All, This is one option . We need to llok at other options At anyrate, the apportionment of representation is an important issue. There is no equal footing between SO ,AC as some wouls have more qwider representation which should be respected. Regards Kavouss ---------- Forwarded message ---------- From: Drazek, Keith <kdrazek(a)verisign.com> Date: 2015-01-28 20:58 GMT+01:00 Subject: Re: [CCWG-ACCT] got some lawyerly answers on membership structure To: "accountability-cross-community(a)icann.org" < accountability-cross-community(a)icann.org> Eric, To be clear, no one has ever said that, “…only registries can provide the necessary oversight of the Board as it relates to the continued function of the Root Zone Management.” Where did you get that? In order for any accountability structure to be meaningful and acceptable, it should represent all members of the community and there should be appropriate balance among all community participants and interests. As an employee of a gTLD Registry and Chair of the GNSO Registries Stakeholder Group, I can state definitively that we have a strong interest in ICANN’s accountability to us and to the rest of the community. I find your suggestion that registries might not have a place in a possible cross-community membership model odd, to say the least. Regards, Keith *From:* accountability-cross-community-bounces(a)icann.org [mailto: accountability-cross-community-bounces(a)icann.org] *On Behalf Of *Eric Brunner-Williams *Sent:* Wednesday, January 28, 2015 12:51 PM *To:* accountability-cross-community(a)icann.org *Subject:* Re: [CCWG-ACCT] got some lawyerly answers on membership structure On 1/28/15 8:50 AM, Drazek, Keith wrote: If a ccTLD manager is not a member of the ccNSO, is paying no fees to ICANN and is not bound by ccNSO policy, please help me understand how they are impacted and why they would care about the ICANN Board's accountability mechanisms to its community. I fully understand why every TLD registry cares about the IANA functions and changes to the root zone file, but our issue of greater ICANN Accountability is a broader discussion than the IANA-specific concerns and accountability mechanisms currently being addressed via the CWG Transition. It is not so very long ago that a (previous) Executive and (previous) Board made changes requested by delegees of iso3166 code points conditional upon a form of agreement. The policy pursued by that Executive and that Board were not subject to substantive community review (notice and comment) prior to being implemented, with the accountability issue I hope many, not just the directly concerned, still recall. Additionally, the interests of parties (of any type) need not encompass the union of all interests of all parties in the mechanisms and policies relating to accountability. The pursuit of the narrow self-interest of a hypothetical ccTLD, or gTLD, delegee or contractual party, through its operator, should not, by itself, remove a party pursuing its narrow self-interest from what ever may eventually be a body of "members". Were it so, the removed would be at least some of those the USG observed in the AOC which constitute " a group of participants that engage in ICANN's processes to a greater extent than Internet users generally." However, given the general awareness that the continued function of the Root Zone Management (RZM) partners is of fundamental importance, and the limited interest _as_delegees_or_contractees_ in issues other than the continued function of the Root Zone Management (RZM) partners, it seems unnecessary to encumber the problem of accountability-via-membership (already quite difficult if not intractable, in my opinion) with notions that delegees and contractees, as delegees or contractees, contribute an interest absent but for their status as "members", whether represented en toto, or as self-organized aggregates, or by lottery. In simple terms, why registries-as-members at all? Does anyone believe only registries can provide the necessary oversight of the Board as it relates to the continued function of the Root Zone Management? I think that the function of the Board is general oversight of the registries, arising from its technical coordination of unique endpoint identifiers delegated authority, and contractual oversight arising from its delegated contracting authority, so the assumption that registries have a necessary place in a hypothetical membership model is one that should be examined carefully for self-interest and self-dealing, as well as for necessity and utility. Eric Brunner-Williams Eugene, Oregon _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

1 0

Fwd: draft response to Lise and Jonathan
by Avri Doria Jan. 27, 2015

Jan. 27, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I sent the following in reply: > > > Seems mostly ok. On the IAP, I thought there was also an element where the proposals may not be aligned and that CWG needed to also explore its own mechanisms. > > Also, should i should send it on to the WA 3 - am i authorized to do so. > > thanks > > avri Got authorization to pass it on in the phone call. And asked for a day to reply. Note I will be reporting on this in the CWG meeting on Thursday, so would like this sent before then, avri - -------- Forwarded Message -------- Subject: draft response to Lise and Jonathan Date: Tue, 27 Jan 2015 19:55:45 +0100 From: Thomas Rickert <rickert(a)anwaelte.de> To: Avri Doria <avri(a)acm.org> Hi Avri, we have prepared a response to Lise and Jonathan, which you find below. As promised, we keep you in the loop. Are you ok with us sending it as is? Thanks, Thomas Dear Lise and Jonathan, Thank you for the very useful call last Friday, 23 January. It was helpful to hear updates from the CWG, and I hope the overview we provided of the CCWG's face-to-face meeting, Frankfurt 19-20 January, was informative and showed we are working in the same direction. We held a session in Frankfurt to discuss the draft "CWG-Stewardship accountability dependencies" document, and the summary outcome of that discussion follows. You can also find details of the session, including staff notes and transcript on the CCWG wiki https://community.icann.org/pages/viewpage.action?pageId=51418500 (noting that the draft is a living document and we held our discussions on 19 January. • Budget Accountability and Transparency While the CCWG is considering reinforcing ICANN's accountability with regards to budget, the mechanisms would most probably not specifically address the IANA budget. Therefore we encourage the CWG to recommend measures to enhance transparency regarding the IANA budget, we will support requests for increased transparency. • Accountability for (re)delegations To the extent that the Board may take decisions on this area, CCWG intends to recommend accountability mechanisms that would be relevant and supportive. We expect to recommend a strengthened reconsideration process for Board as well as management/staff decisions. • Independent Review of Board Actions CCWG is discussing introducing binding mechanisms of redress to the independent review process for certain decisions of the Board. We are very much in tune with CWG approach. • Independent Appeals Panel We expect CCWG recommendations to be supportive to the CWG proposals, we aligned in our thinking/approach. • Control over ICANN Board decisions. When we met, this was a new section of the document and CCWG members had not had chance to review before the meeting. The CCWG is now considering options to challenge and overturn ICANN Board decisions. We are very aware of the need for caution so as not to undermine the bottom-up nature of the ICANN policy decision-making process. Community oversight of Board decisions would probably not extend to the ability to mandate a specific decision, but rather to overturn a Board decision or require the Board to make a decision in the case of inaction. This avenue of work will be one of the focuses of CCWG attention for the coming weeks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUx+R/AAoJEOo+L8tCe36H0kUH/0tfzmiRYrLaAjzqU5KygxkO hIV6T5i5tFfjssevYGIQdRwDgzsaEdYPY763nMXz9vYmgfiB03tlfL0CCCtC4Bxx d26VdihXAjlNX15aNw8RB9h/fG++VxTn0k3ELGDzwhscuRoaoGLlI7fd3Z971jE8 KTjUaKJ16qmDs/xO5IK2bS6O+vUi6IBsgmtVFD2rdnImJPT6rGNdZN32MiutR+o+ vdiYpidU22/oWfb7IjQsIq4GZj6fS32VqGDln4ZVNQRvYan7jZnHC3zH0H+tdJ5M 2zCw/o48NtEPUjLbxZHhy18jyyJ3NLS8sY8Z+ZHeZtP5pn53Sv8YWETxf7NcyC0= =FHQR -----END PGP SIGNATURE-----

1 0

Snapshot of CW-Stewardship Accountability dependencies
by Avri Doria Jan. 18, 2015

Jan. 18, 2015

Hi, Apologies for this last minute contribution to our meeting, but the CWG is still developing its solution and it has proven challenging to nail down the accountability dependencies. The attached document, is a draft/snapshot of where we have gotten to at this point. The issues are still under discussion as we have both the mainstream 'Frankfurt' model that was the subject of our comment draft and have several alternative 'Internal model' proposals that are being discussed based on comments received. Some of these dependency concerns may be more applicable to one model than another, but even that is still difficult to accurately delineate. Also in some instances, like the IAP (Independent Appeals Panel) we have yet to 'decide' whether this uses a mechanism that the CCWG-Accountability might create or is a structure the transition team builds separately. The dependencies paper is short and does not include much by way of description or explanation - the Stewardship solution is still under discussion. I will be happy to provide as much explanation as I can during the meeting, as I am sure the various other members/participants of the CWG-Stewardship who are attending this week's meeting will do. I will bring back to the CWG-Stewardship any comments the CCWG may have on thses issues. I suggest that the WA3 will be able to continue to dig deeper after our meeting. Thanks avri

1 0

CWG-CCWG issue matrix
by Avri Doria Jan. 15, 2015

Jan. 15, 2015

Hi, I have started building a matrix of the related issues. Only one entry so far, but now that the table is started others can either tell me what to add, or add themselves. https://community.icann.org/display/acctcrosscomm/WS3+-+CWG-CCWG+issue+matr… Do we need to plan on a conference call? Or can we use the table and the email list for a bit. The subject does permeate the other discussion so I am not sure what we would do in a specific meeting on this issue, but perhaps it would be good to have a least one. Please let me know. thanks avri

2 2

Re: [Area 3] [CCWG-Accountability] Work Streams definition
by Kavouss Arasteh Jan. 15, 2015

Jan. 15, 2015

Dear All, I do not understand who agreed with whom What has been changed from the Charter. I personally fully agree with the following Quote "* in the absence “**mechanisms [that] would provide the community with confidence that any accountability mechanism that would further enhance ICANN's accountability ( in relation with work stream 1 of CCWG ,for three distinct areas , Naming, Numbers and Protocols, including parameter ) could be implemented if it had consensus support from the community” the IANA Functions transition should not occur." * *Unquote* *Kavouss * 2015-01-15 16:06 GMT+01:00 Edward Morris <emorris(a)milk.toast.net>: > +1 > > Paul has eloquently expressed my views in a manner far superior to > anything I could write. Thanks. > > One could argue that our current system of accountability and transparency > (reconsideration, Appeal, CEP, IR, DIDP), with some tweaks, should > actually be sufficient going forward. It looks great: on paper. The problem > is that a system designed for redress (per Bruce) actually functions as a > system of review (per Robin), and a rather cursory review system at that. > We simply must have mechanisms designed to ensure that we have real systems > of accountability, ones that does not rely on the good faith and > open-mindedness of any particular Board or staff member or group, in place > before the transition can be allowed to occur. > > -----Original Message----- > From: "Paul Rosenzweig" <paul.rosenzweig(a)redbranchconsulting.com> > To: "'Tijani BEN JEMAA'" <tijani.benjemaa(a)fmai.org.tn>, < > accountability-cross-community(a)icann.org> > Date: Thu, 15 Jan 2015 09:22:26 -0500 > Subject: Re: [CCWG-Accountability] Work Streams definition > > Respetful disagreement. I think the way it describes types of mechanisms > in the “new” definition is exactly what needs to be in place before the > Stewardship transition takes place. Put another way, I think that the > exposition in WS1 precisely describes the commitments that MUST be made > before a transition is allowed to occur. More importantly, I think there > is growing consensus across the community that this is so. To state it > affirmatively – in the absence “mechanisms [that] would provide the > community with confidence that any accountability mechanism that would > further enhance ICANN's accountability would be implemented if it had > consensus support from the community” the IANA Functions transition should > not occur. > > Paul > > ***NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 **** > 509 C St. NE > Washington, DC 20002 > > Paul Rosenzweig > paul.rosenzweig(a)redbranchconsulting.com > <paul.rosenzweigesq(a)redbranchconsulting.com> > O: +1 (202) 547-0660 > M: +1 (202) 329-9650 > Skype: +1 (202) 738-1739 or paul.rosenzweig1066 > Link to my PGP Key > <http://www.redbranchconsulting.com/index.php?option=com_content&view=articl…> > > *From:* Tijani BEN JEMAA [mailto:tijani.benjemaa@fmai.org.tn] > *Sent:* Thursday, January 15, 2015 4:53 AM > *To:* accountability-cross-community(a)icann.org > *Subject:* [CCWG-Accountability] Work Streams definition > > Dear all, > > I read again the new proposed definition of the Work Streams, and I found > it too different from the one in our charter: > > In the charter: > · *Work Stream 1*: focused on mechanisms enhancing ICANN > accountability that must be in place or committed to within the time frame > of the IANA Stewardship Transition; > · *Work Stream 2*: focused on addressing accountability topics > for which a timeline for developing solutions and full implementation may > extend beyond the IANA Stewardship Transition > > The new proposal: > · *Work Stream 1* mechanisms are those that, when in place or > committed to, would provide the community with confidence that any > accountability mechanism that would further enhance ICANN's accountability > would be implemented if it had consensus support from the community, even > if it were to encounter ICANN management resistance or if it were against > the interest of ICANN as a corporate entity. > · All other consensus items could be in *Work Stream 2*, provided > there are mechanisms in WS1 adequate to force implementation of WS2 items > despite resistance from ICANN management and board. > > I don’t believe that we are allowed to change any part of the charter > without going back to the chartering organizations and ask for their > approval. > > On the other hand, the separation of WS 1 and WS 2 was for the purpose of > having the accountability mechanisms necessary before the transition done > in time, and the new definition doesn’t satisfy this requirement > > I would prefer stay with the charter definition for all those reasons > > > -------------------------------------------------------------------------------- > *Tijani BEN JEMAA * > Executive Director > Mediterranean Federation of Internet Associations (*FMAI*) > Phone: + 216 41 649 605 > Mobile: + 216 98 330 114 > Fax: + 216 70 853 376 > > -------------------------------------------------------------------------------- > > > > > > ------------------------------ > <http://www.avast.com/> > Ce courrier électronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! <http://www.avast.com/> est > active. > > > > _______________________________________________ > Accountability-Cross-Community mailing list > Accountability-Cross-Community(a)icann.org > https://mm.icann.org/mailman/listinfo/accountability-cross-community > >

2 1

Re: [Area 3] [Internal-cg] RFP, CCWG-Accountability, and timeline
by Kavouss Arasteh Jan. 15, 2015

Jan. 15, 2015

Alissa Thankj you very much for that explanation However, I draw your attention to the part of the CCWG Charter as ststed below: Quote “In the discussions around the accountability process, the CCWG-Accountabili ty will proceed with two Work Streams: · *Work Stream 1: focused on mechanisms enhancing ICANN accountability that must be in place or committed to within the time frame of the IANA Stewardship Transition*; Whereas · *Work Stream 2: focused on addressing accountability topics for which a timeline for developing solutions and full implementation may extend beyond the IANA Stewardship Transition* *In that sense , ICG is expected to receive the results of activities of Work Stream 1 .No doubt the activities of that Work Stream should include but not limited to cover the outcome of the CWG accountability part on naming . * *Moreover, Work Stream 1 shall also receive the inputs from **for **CRISP( for numbers ) **; and from **IANAPLAN.( foir protocol and parameters ) .* *In other words all accountabilities relating to Naming, Numbers , and proptocol including parapametrs ,irrespective their transmission to ICG as You have mentioned , must be seen together in a pachkage by CCWG under Work Stream 1. .Without that information from CCWG the accountability actions referred to in WS1 IANA TRANSITION WOULD NOT TAKE PLACE.* *This is an issue that must be discussed in CCWG thoroughly.* *Moreover, I do not understand the term “ CONDITIONAL ACCOUNTABILITY” the accountability is not coherenet and understandable with such qualification.* *In addition the results of CWG ,efven if it come to ICG at the end of Januar , it must have the consensus of community . I have doubt that community would have sufficient time to comment on the output of CWG.* *I therefroe see a major difficulty here that such a proposal may come from CWG at the end of Jan. 2015 without being sufficiently discussed by the community and not reached consensus.* *We are rushing to do something which may have serious inconsistencies . * *Regards* *Kavouss * 2015-01-15 7:49 GMT+01:00 Joseph Alhadeff <joseph.alhadeff(a)oracle.com>: > Agreed. > > Sent from my iPad > > On Jan 14, 2015, at 6:22 PM, Drazek, Keith <kdrazek(a)verisign.com> wrote: > > Thanks Alissa, > > > > I think this is spot on. > > > > Best, > > Keith Drazek > > > > *From:* internal-cg-bounces(a)icann.org [ > mailto:internal-cg-bounces@icann.org <internal-cg-bounces(a)icann.org>] *On > Behalf Of *Alissa Cooper > *Sent:* Wednesday, January 14, 2015 6:05 PM > *To:* ICG > *Subject:* [Internal-cg] RFP, CCWG-Accountability, and timeline > > > > Kavouss started a discussion on our call earlier today concerning the > relationship between the CCWG-Accountability and the ICG, and since we ran > the call right down to the end, I wanted to reiterate some points here and > make sure we are all on the same page. > > > > In our RFP < > https://www.icann.org/en/system/files/files/rfp-iana-stewardship-08sep14-en…> > we asked for a complete formal response from each of the operational > communities: names, numbers, and protocol parameters. Each community was > convened in its own way and chartered its own group to develop an RFP > response. The group that was created for names was the CWG; for numbers it > was CRISP; and for protocol parameters it was IANAPLAN. > > > > RFP Section III asks the communities to detail the changes they propose to > the existing IANA oversight and accountability mechanisms. If any proposal > that gets sent to us does not include these details, we will have to send > it back to the community to be completed. We cannot proceed with proposals > that are missing the oversight and accountability component. > > > > We set January 15 as a target for receiving responses from the > communities. For the ICG, this is the first step in the process — not the > last. We have explained the full process that will take place over the rest > of the year to get from individual community proposals to a final proposal > for submission to NTIA < > https://www.icann.org/en/system/files/files/iana-transition-assembly-finali…>. > As such, while the responses we receive from the communities need to be > complete in detailing their proposed transition plans, those plans need not > be actually implemented before the responses are submitted to the ICG. > > > > Indeed, one feature that all of the proposals may end up having in common > is that they create expectations or conditions that must be met or steps > that must be carried out before the transition itself may take place (but > not before the proposal is submitted to the ICG), and that various other > bodies may need to act to meet those conditions or take those steps. For > example, the CWG proposal might outline accountability measures that it > expects the CCWG-Accountability to take up. The CRISP proposal might > outline steps it expects the RIR legal teams to take on. The IANAPLAN > proposal lists a couple of expectations about acknowledgements it expects > other parties to make. > > > > I think it’s perfectly fine — and expected — for the proposals to have > this feature when they come to us. We didn’t ask the communities to finish > the implementation of the transition. We asked them to propose plans. We > have many months of further review and public comment in front of us, and > we have established that if issues arise further down the line, we will > send the proposals back to the communities to work those issues out. Thus > if we receive a proposal that puts a condition on another body and it turns > out that that body cannot or will not fulfill the condition, we have both > the time and the process in place to work through it. I hope we won’t have > to do that, but we’ve built our process to accommodate it. > > > > Alissa > > > > > > _______________________________________________ > Internal-cg mailing list > Internal-cg(a)icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > > > _______________________________________________ > Internal-cg mailing list > Internal-cg(a)icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > >

1 0

Comments on accountabilty
by Kavouss Arasteh Jan. 12, 2015

Jan. 12, 2015

Dear Mathieu Dear All Please find attached my comments on the document provided by mathieu on accountabilty Regards Kavouss

1 0