- Ccwg-accountability2 - lists.icann.org

Re: [Area 2] [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 2] [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 > >

1 0

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

Mining the Work Area 2 inventory for 'Requirements'
by Steve DelBianco Jan. 19, 2015

Jan. 19, 2015

Chairs — to help kick things off tomorrow and to use some of the prior of work area 2, I went thru our 15-Jan version of WA2 inventory and extracted some requirements. Just did the first page here. We could do the second and third page too, if you think that will be helpful. Note1: ‘Community’ refers to cross-community accountability group, whether by Members, Supervisory Board, or other mechanism. Community powers: Community appoints representatives to the Affirmation of Commitments Review Teams. Community has standing to send any board decision to independent Review Panel (may begin the IRP with a Cooperative Engagement Process) Community has standing to begin a reconsideration request on decisions of board or ICANN management, on matters of process or of substance. Community may approve/disapprove proposed ICANN annual budget. Community may approve/disapprove proposed changes to ICANN bylaws or Articles of Incorporation. Community may recall one or all ICANN board members. Review and Redress Mechanisms: Decisions of Independent Review Panel are binding on ICANN’s board. Panelists in the IRP pool should be selected by the Community. The standard for Independent Review should be lower. The cost to prosecute an Independent Review should be reduced. IRP should address errors or ethical lapses. Ombudsman should be able to investigate any accountability-related complaint brought by an ICANN employee, while protecting confidentiality of the employee Affirmation of Commitments: The Affirmation of Commitments should not be a bilateral agreement with USG that can be canceled by either party. It could be merged into ICANN bylaws, for example. The Accountability & Transparency Review Team (ATRT) could recommend sunset of previously required reviews, and create new reviews. Mission/Scope of ICANN: ICANN should be prevented from imposing obligations on others, unless supported by consensus of affected parties and necessary to protect the integrity and availability of unique identifiers in the DNS. ICANN should be prevented from acting outside its Bylaws and Articles — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org<http://www.netchoice.org/> and http://blog.netchoice.org<http://blog.netchoice.org/> +1.202.420.7482

2 1

Re: [Area 2] [CCWG-Accountability] Work Streams definition
by Robin Gross Jan. 16, 2015

Jan. 16, 2015

I support Matthew's points and amendments. Thanks, Robin On Jan 16, 2015, at 12:07 AM, Fares, David wrote: > I support Matthew’s comments and amendments as well. > > From: accountability-cross-community-bounces(a)icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Drazek, Keith > Sent: 15 January 2015 16:27 > To: Burr, Becky; Matthew Shears; Jordan Carter; Kavouss Arasteh > Cc: ccwg-accountability3; ianatransition(a)icann.org; ccwg-accountability2(a)icann.org; ccwg-accountability1(a)icann.org; accountability-cross-community(a)icann.org > Subject: Re: [CCWG-Accountability] [Area 2] Work Streams definition > > +1 from me too. I support Matthew’s points…it’s both. > > From: accountability-cross-community-bounces(a)icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Burr, Becky > Sent: Thursday, January 15, 2015 11:19 AM > To: Matthew Shears; Jordan Carter; Kavouss Arasteh > Cc: ccwg-accountability3; accountability-cross-community(a)icann.org; ccwg-accountability2(a)icann.org; ccwg-accountability1(a)icann.org; ianatransition(a)icann.org > Subject: Re: [CCWG-Accountability] [Area 2] Work Streams definition > > +1 > > 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 > > From: Matthew Shears <mshears(a)cdt.org> > Date: Thursday, January 15, 2015 at 11:16 AM > To: Jordan Carter <jordan(a)internetnz.net.nz>, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> > Cc: ccwg-accountability3 <ccwg-accountability3(a)icann.org>, "ccwg-accountability2(a)icann.org" <ccwg-accountability2(a)icann.org>, "ianatransition(a)icann.org" <ianatransition(a)icann.org>, "ccwg-accountability1(a)icann.org" <ccwg-accountability1(a)icann.org>, Accountability Community <accountability-cross-community(a)icann.org> > Subject: Re: [Area 2] [CCWG-Accountability] Work Streams definition > > Not to belabor this much more, and I may be being pedantic... > > It appears to read as if WS1 is about putting in place mechanisms that "provide the community with confidence" but not specifically about putting in place accountability mechanisms or measures. There is a big difference between putting in in place process mechanisms to provide confidence (as it now seems to imply) and putting in place actual accountability mechanisms which is what the original definition suggested. The second definition is fine for so long as it explicitly includes the first as well. > > It might be better if it read something like: > > Work Stream 1: is focused on mechanisms that 1) enhance ICANN's accountability and must be in place or committed to within the time frame of the IANA Stewardship Transition, and 2) that provide the community with confidence that any accountability measures 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. > > Matthew > > > > On 1/15/2015 10:40 AM, Jordan Carter wrote: > I agree with Paul, Mathieu etc - the Charter language is the skeleton. The language proposed sets out to characterise why we would select items - i.e. why they have to be done before the transition. > > We have to set out transparently the criteria we are using to decide what has to be in place. This language helps do that. > > best > Jordan > > On 16 January 2015 at 04:17, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> wrote: > 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 > O: +1 (202) 547-0660 > M: +1 (202) 329-9650 > Skype: +1 (202) 738-1739 or paul.rosenzweig1066 > Link to my PGP Key > > 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 > -------------------------------------------------------------------------------- > > > > > > > Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! est active. > > > _______________________________________________ > Accountability-Cross-Community mailing list > Accountability-Cross-Community(a)icann.org > https://mm.icann.org/mailman/listinfo/accountability-cross-community > > > > _______________________________________________ > Ccwg-accountability2 mailing list > Ccwg-accountability2(a)icann.org > https://mm.icann.org/mailman/listinfo/ccwg-accountability2 > > > > > -- > Jordan Carter > > Chief Executive > InternetNZ > > 04 495 2118 (office) | +64 21 442 649 (mob) > jordan(a)internetnz.net.nz > Skype: jordancarter > > To promote the Internet's benefits and uses, and protect its potential. > > > > > > _______________________________________________ > Accountability-Cross-Community mailing list > Accountability-Cross-Community@icann.orghttps://mm.icann.org/mailman/listinfo/accountability-cross-community > > > > -- > Matthew Shears > Director - Global Internet Policy and Human Rights > Center for Democracy & Technology (CDT) > mshears(a)cdt.org > + 44 771 247 2987 > This message and its attachments may contain legally privileged or confidential information. It is intended solely for the named addressee. If you are not the addressee indicated in this message (or responsible for delivery of the message to the addressee), you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments that does not relate to the official business of Twenty-First Century Fox, Inc. or its subsidiaries must be taken not to have been sent or endorsed by any of them. No representation is made that this email or its attachments are without defect. _______________________________________________ > Accountability-Cross-Community mailing list > Accountability-Cross-Community(a)icann.org > https://mm.icann.org/mailman/listinfo/accountability-cross-community

1 0

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

Jan. 16, 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 > >

6 6

CCWG Work Area 2 (inventory of accountability suggestions -- updated 15-Jan-2015
by Steve DelBianco Jan. 16, 2015

Jan. 16, 2015

here’s a follow-up for Work Area 2 (WA2) arising from our 13-Jan call (link<https://community.icann.org/pages/viewpage.action?pageId=51414985>). (Will post these to the WA2 wiki soon as I can get access) First, I updated the WA2 inventory to reflect the new proposed definition for Work Stream 1 (WS1), as discussed on our 13-Jan call. Second, I updated the inventory to reflect additional Accountability suggestions and detail provided by Malcolm Hutty, the GNSO-NCSG (Non-Commercial Stakeholders Group), Robin Gross, Milton Mueller, the GNSO-IPC (Intellectual Property Constituency), and David Johnson. As rapporteur for WA2 I am trying to accommodate all suggestions, but also looking forward to the exercise of prioritizing this ever-expanding list of accountability mechanisms. Regards, Steve — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org<http://www.netchoice.org/> and http://blog.netchoice.org<http://blog.netchoice.org/> +1.202.420.7482

1 0

Re: [Area 2] [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

A paper of possible interest
by Paul Rosenzweig Jan. 13, 2015

Jan. 13, 2015

Participants might be interested on this paper from the Global Commission on Internet Governance: https://www.cigionline.org/sites/default/files/gcig_paper_no3.pdf It touches on many of the issues we have been considering. Regards Paul **NOTE: OUR NEW ADDRESS BELOW, EFFECTIVE 12/15/14 *** Paul Rosenzweig Red Branch Consulting, PLLC 509 C St. NE Washington, DC 20002 paul.rosenzweig(a)redbranchconsulting.com <mailto:paul.rosenzweigesq@redbranchconsulting.com> O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 www.redbranchconsulting.com <http://www.redbranchconsulting.com/> www.paulrosenzweigesq.com <http://www.paulrosenzweigesq.com/> Link to my PGP Key <http://www.redbranchconsulting.com/index.php?option=com_content&view=articl e&id=19&Itemid=9>

3 2

Fwd: Re: [Area 4] Business Constituency Stress Test #1
by Malcolm Hutty Jan. 12, 2015

Jan. 12, 2015

The second part of the message below, which was part of a discussion in Area 4, uncovered what is suggested may be a flaw in our criteria for distributing items between WS1 and WS2. I therefore draw it to the attention of this subgroup. -------- Forwarded Message -------- Subject: Re: [Area 4] Business Constituency Stress Test #1 Date: Mon, 12 Jan 2015 12:47:37 +0000 From: Malcolm Hutty <malcolm(a)linx.net> To: Steve DelBianco <sdelbianco(a)netchoice.org>, Eric Brunner-Williams <ebw(a)abenaki.wabanaki.net>, mathieu.weill(a)afnic.fr <mathieu.weill(a)afnic.fr>, rickert(a)anwaelte.de <rickert(a)anwaelte.de>, leonfelipe(a)sanchez.mx >> León Felipe Sánchez Ambía <leonfelipe(a)sanchez.mx> CC: ccwg-accountability4(a)icann.org <ccwg-accountability4(a)icann.org> Eric Brunner-Williams wrote: > Would you be so kind as to convey the Business Constituency's > assigned probability for: > > 1. termination of the AoC between the USG and the incumbent > contractor, by the USG, while leaving the IANA Functions contract > otherwise unchanged? > > 2. termination of the AoC between the USG and the Corporation, by the > Corporation, while retaining the IANA Functions contract otherwise > unchanged? On 12/01/2015 01:59, Steve DelBianco wrote: > Eric — there is no need to assign probabilities for contingencies or > for consequences. I refer you to the charter for our CCWG > <https://community.icann.org/display/acctcrosscomm/Charter>, > regarding scenarios: That's fair enough, but in this case I think Eric's question prompts a useful thought. The explicitly announced intention of the NTIA is to transition the USG's historic role in stewardship of the DNS to the community. At the same time, the clear expectation of many governments and others is that transition should bring about a situation where the US no longer has a privileged relationship with ICANN, and especially no special ability to set requirements and enforce them. The AoC is part of the NTIA's historic stewardship role. I am sure that many people will also regard it as an example of the privileged relationship USG has that they wish to see ended. Not necessarily because they disagree with its content, but because they object to its form. So I would regard it as entirely plausible and, sooner or later, quite likely that either ICANN or the USG might terminate the AoC. More likely, both together will do so by agreement. The reason for terminating would be that it is a mechanism that belonged to the era of USG stewardship. Accordingly, insofar as the AoC contains items relevant to accountability, it is the responsibility of this CCWG to identify them and propose how they may be continued or replaced in a post-NTIA world. Listing this as a "contingency" is, to my mind, just a convenient way of ensuring it is on our agenda. The thought that Eric's question prompts is that maybe this discloses a flaw in our criteria for the WS1/WS2 distinction. WS1 is for items that must be dealt with (implemented, or firmly committed) prior to or as part of transition. We have been assuming that this just means those things which are necessarily to give assurance that the rest of the improvements can be implemented later. When we consider the AoC requirements relevant to accountability (and also requirements of the IANA functions contract that are relevant to ICANN accountability beyond IANA) it is immediately apparent that it is an error to assume we need only consider improvements. There are existing mechanisms for accountability as well. Surely, it should be a precondition for transition to ensure that existing accountability functions are continued without interruption? Surely, it is not sufficient that we merely have in place a mechanism to re-institute them later? If this is so, then the criteria for WS1 ought to accomodate that. I shall therefore also forward this message to Area 2. Kind Regards, Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ 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 _______________________________________________ Ccwg-accountability4 mailing list Ccwg-accountability4(a)icann.org https://mm.icann.org/mailman/listinfo/ccwg-accountability4

2 1