- Ccwg-accountability1 - lists.icann.org

Re: [Area 1] [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 1] Petition Process
by Kavouss Arasteh Oct. 12, 2015

Oct. 12, 2015

Dear Jordan, Thank you very much for your kind reply. First of all there a clear contradiction in what you described with which I fully agree and the reply you did provide in the last WPè1 call in saying " Kavous , there is n voting in the petition stage " Now you confirmed what is described Under petition general introduction the each So or AC that launches a petition first must agree on the petition by simple majority .That is VOTING what you did not agree at the last CALL sECOND ,THERE IS INCONSISTENCIES BETWEEN VARIOUS PARTS OF CHATER 7 ( 7.1, 7.2, 7.3 and 7.4 ) WITH THAT REFERRED TO IN 368. Regards Kavouss 2015-10-12 1:51 GMT+02:00 Jordan Carter <jordan(a)internetnz.net.nz>: > hi Kavouss, all: > > Let me try and be clear - I don't think there is a contradiction here, but > let's see what you think. > > The petition step is an SO or AC choosing to trigger the use of a power. > If the petition happens, then there is the community discussion in the > Forum, and then the right for everyone to vote (or express a consensus > view, if we change to that) on whether the power is used. > > There has to be some way to "start the process". The petition step is the > start. > > To create a petition, an SO or AC would have to decide to do it. That's > the voting you quote - the "simple majority" - the idea was each SO or AC > follows its usual process, not a supermajority one. > > Once the SO or AC decides and if it decides to do the petition, then the > petition is lodged and the whole SO/AC community is told "A petition has > been received from ____ SO, and so the question of using the community > power is now asked." > > Then the discussion phase. > > After that, the decision phase, when all the participating SOs or ACs > decide whether or not the power should be used. That could be voting, or > the new community consensus approach we are discussing. > > > I don't see any contradiction here. What do you think, Kavouss, all? > > cheers > Jordan > > > > On 12 October 2015 at 03:21, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> > wrote: > >> Dear Co-Chairs >> >> As I did mention at several occasions there number of inconsistencies >> between various part of the second Draft Proposals some of which I raised >> and some others I did ask to be checked by the authors of these parts. >> >> One of these inconsistencies are the petition process, >> >> 368 stipulate that >> >> Quote >> >> "*To trigger community consideration for the use of a community power, >> an SO or AC has to agree by a resolution of its governing Body that the >> power should be used - the threshold to agree the resolution is a simple >> majority" *( means voting ,emphasis is added ) >> >> Unquote >> >> At the last WP1 I raised the same question, but Jordan replied that >> >> At the level of potion no voting is required ? >> >> What is wrong and what is right? >> >> Is the statement in paragraph 368 as quoted above is correct? Or if the >> explanation by Jordan is correct? >> Moreover sub-section 7.3 and 7.4 do not make any clear reference in which >> the petition is carried out whereas sun-section 7.3 and 7.4 referred to >> that process. >> >> In addition to that , in regard with Fundamental Bylaws the situation is >> not clearly mention in regard with initiation of petition in each SO and or >> AC? >> >> Consequently, there is a need to closely look at the issue and other >> inconsistencies which may exist, >> >> Regards >> >> Kavouss >> > > > > -- > Jordan Carter > > Chief Executive > *InternetNZ* > > +64-4-495-2118 (office) | +64-21-442-649 (mob) > Email: jordan(a)internetnz.net.nz > Skype: jordancarter > Web: www.internetnz.nz > > *A better world through a better Internet * > >

1 0

Petition Process
by Kavouss Arasteh Oct. 11, 2015

Oct. 11, 2015

Dear Co-Chairs As I did mention at several occasions there number of inconsistencies between various part of the second Draft Proposals some of which I raised and some others I did ask to be checked by the authors of these parts. One of these inconsistencies are the petition process, 368 stipulate that Quote "*To trigger community consideration for the use of a community power, an SO or AC has to agree by a resolution of its governing Body that the power should be used - the threshold to agree the resolution is a simple majority" *( means voting ,emphasis is added ) Unquote At the last WP1 I raised the same question, but Jordan replied that At the level of potion no voting is required ? What is wrong and what is right? Is the statement in paragraph 368 as quoted above is correct? Or if the explanation by Jordan is correct? Moreover sub-section 7.3 and 7.4 do not make any clear reference in which the petition is carried out whereas sun-section 7.3 and 7.4 referred to that process. In addition to that , in regard with Fundamental Bylaws the situation is not clearly mention in regard with initiation of petition in each SO and or AC? Consequently, there is a need to closely look at the issue and other inconsistencies which may exist, Regards Kavouss

1 0

Re: [Area 1] [CCWG-ACCT] Your public comment re replacement of IANA provider
by Bruce Tonkin Sept. 22, 2015

Sept. 22, 2015

Hello Eberhard, >> would you be willing to share your "understanding" why you are seeking to introduce ICP-1 into Garnishee-Appellee's Unopposed Motion for Leave to File a Supplemental Appendix (USCA Case #14-7193 Document #1573369) I don't know anything about this - but will ask the ICANN legal team when I get into LA. >> while at the same time my understanding is that you agreed with ICP-1 being archived (as not ever having been policy)? I assume you are asking what the status is of the ICP-1 document. Again I will seek advice from staff and other Board members that are more familiar with the topic when I get into LA later this week. Is this part of the CCWG proposal in some way? Regards, Bruce Tonkin

1 0

Human Rights
by Kavouss Arasteh July 31, 2015

July 31, 2015

Dear All, Robin sent the following Quote Dear All Grec ,s proposal is more broad and more complete than Keith , s proposal as human tights is not limited to freedom if expression and free flow of information but covers other areas such tight to education , rights to asylem and so on Dear Mr. Nafez Pls kindly send the following message through Mr. Darvishi to Rancy To Mr. Rancy ...... Submission by Admins ...,. Low Erp/ Eirp assignments under Article 4 if GE 06 Agreement Dear Mr. Rancy As our representative at WP 6A and SG 6 discussed with you, we have noted that Admin.,...x .,.have sent request for modification to GE 06 Agreement in which submitted many low power assignments which theoretically do not cause interference to the Plan but once included in the Plan would require protection from any subsequent modification to the Plan . The main purpose of such abnormal and impractical submission is to block the proper application of the Plan by neighbouring countries among which porously pointed toward the very right And interest of this Administration. This tricky approached was already practiced in other Regional terrestrial and space Plans in the past The RRB Rules of Procedure clarified the governing procedure do as such inclusionSHALL NOT be granted any protection beyond the level that they entered in the Plan. In view of the above this administration formally declare that it will not protect these assignment beyond the agreed level based on which the Plan was established and thus these assignments once Entered in the Plan would operate on Non Protection basis from any subsequent modification to the Plan Regard Sent from my iPhone On 31 Jul 2015, at 01:49, Robin Gross <robin(a)ipjustice.org> wrote: I wish to mention that Article 19 of UNDHR has a limited scope . It does not cover other elements of HR that are in other Covenant, Agreement and so on These other documents relating to HR addresses other elements of Human rights such as Rights to Education, Rights to Asylum, Right to non discriminatory treatment and and ... Consequently Grec,s Proposal is more wider as it refers indirectly to these other rights However, My proposal which got a clear majority 8 in favors and 4 against compared to Grec,S proposal 11 in favour and 8 Against 9 those favored Keith,s proposal and Keith ,s proposals 8 in favour and 11 against ( those voted for Grec,s proposal Thus my proposal stand for inclusion in the NBylaws Regards Kavouss ,.

1 0

Impact assessment questions on CCWG Proposal
by Bruce Tonkin June 19, 2015

June 19, 2015

Hello All, In the public comments from the Board at: http://forum.icann.org/lists/comments-ccwg-accountability-draft-proposal-04… The Board noted that it would be useful to have an impact analysis where the costs, benefits, and alternatives to proposals are weighed to assure that the design of the solution for each issues is the most efficient, least burdensome on the community , and the most cost-effective solution. We have prepared the attached detailed list of questions to help the CCWG with that impact analysis. Many of the questions likely have straight forward answers that can be prepared as part of a "FAQ" on the final proposal, and some questions really highlight trade-offs that need to be made, and the questions aim to help flesh out those trade-offs. Every major change to a system, usually results in some secondary effects. Often we can live with those secondary effects, but it is useful to think how to mitigate some of these secondary effects in the proposal. The Board hopes these will be helpful to the group in its full day session in Buenos Aires and welcomes hearing from the CCWG on Sunday. Unfortunately I don't arrive in Buenos Aires until Tuesday evening - but will endeavour to spend as much time as possible with you all in Buenos Aires and to help clarify any concerns raised by Board members. I also intent to attend the face-to-face meeting in July. Regards, Bruce Tonkin CCWG Board Liaison

1 0

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

Re: [Area 1] [Internal-cg] ICANN52
by Kavouss Arasteh Feb. 14, 2015

Feb. 14, 2015

Keith I strongly recommend that no action be taken by co chairs who in fact are the origin of this misunderstanding The situation is clear . ICG will receive input from CCWG indirectly through CWG , the latter will take into account output of Work stream 1 of CCWG No need any intervention of ch chairs at all Kavouss Sent from my iPhone > On 13 Feb 2015, at 23:40, Drazek, Keith <kdrazek(a)verisign.com> wrote: > > Thank you Kavouss. Since this has been a recurring discussion, perhaps our Co-Chairs could send a request for clarification to Dr. Crocker to ensure we're all on the same page. In my mind, it's really a question of formality...the CCWG is not required to submit anything to the ICG, but the ICG may certainly receive input from the CCWG and assess it accordingly. I have no objection to us doing so. > > Regards, > Keith > > Sent from my iPhone > > On Feb 13, 2015, at 6:52 AM, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> wrote: > >> Dear Keith >> No it does not >> Report of CCWG work Stream 1 needs to be duly considered by ICG in a direct or indirect manner. >> Report of CCWG work stream 1 to ICANN may be rejected by ICANN thus if that report on accountability is not reached or considered by ICG the objectives specified by NTIA would not be met. >> By the way you may be in the same camp of the person that I referred to but you were not the one who said ICG need not any input from CCWG . It was someone else . Any way that statement to which you associate yourself is not correct >> Kavouss >> >> Sent from my iPhone >> >> On 13 Feb 2015, at 18:48, Drazek, Keith <kdrazek(a)verisign.com> wrote: >> >>> Hi Kavouss, >>> >>> I believe you are referring to my previous statements that the ICG is not expected to receive, incorporate or deliver a proposal from the CCWG Accountability. I stand by that statement. I did not say there would be no interaction or input exchanged among the various groups. >>> >>> Technically speaking, the CCWG Accountability will deliver its official report directly to the ICANN Board and not to the ICG. The ICG will only formally coordinate, consolidate and submit the proposals from the 3 operational communities, including from the CWG-Naming. The ICG and CCWG are currently on parallel tracks. >>> >>> Steve Crocker's new comment that the ICANN Board expects the ICG to "take into account the accountability mechanisms recommended by the CCWG" and that the CCWG and ICG proposals should be coordinated is not inconsistent with my statement. It is a clarifying remark that recognizes the two parallel tracks must be coordinated and informed by one another, and I believe it increases the importance of our work as ICG Liaisons to the CCWG. >>> >>> That said, I expect most of the CCWG and CWG coordination to take place directly between those two groups as has already begun. >>> >>> We will need to watch carefully for any potential conflicts, unnecessary duplication and gaps as the CCWG and CWG conduct their work. As Patrik has noted, "input" can and will be exchanged among the various groups, but does not mean submission and receipt of a formal proposal from the CCWG to the ICG. >>> >>> I hope this helps clarify the intent of my remarks. >>> >>> Regards, >>> Keith >>> >>> >>> On Feb 13, 2015, at 1:03 PM, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> wrote: >>> >>>> Dear Patrik >>>> Let us not play with words >>>> Someone in ICG clearly told that ICG does not expect any input from CCGG work stream 1 >>>> I did not agree to that statement now Milton very rightly remind all of us that there is a direct link between ICG and CCWG work stream 1 . >>>> Tks Kavouss >>>> >>>> >>>> Sent from my iPhone >>>> >>>> On 13 Feb 2015, at 10:38, Patrik Fältström <paf(a)frobbit.se> wrote: >>>> >>>>> >>>>>> On 13 feb 2015, at 09:15, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> wrote: >>>>>> >>>>>> 'ICG does not expect any input from CCWG .I did severely disagree with that statement but since no one else than me raised that issue I did not raise it again but in CCWG I mentioned that the sole purpose of Work Steam 1 was exactly to provide the accountability required to be in place or committed before transition is take place. >>>>> >>>>> My view: >>>>> >>>>> There is no contradiction between the two statements. It is all a question on what you mean by "input from". >>>>> >>>>> The ICG and CCWG are parallell, so none of the two groups report to each other. >>>>> >>>>> There is though [of course] a requirement that there is no contradiction between the two outputs. >>>>> >>>>> Because of that, coordination is needed. >>>>> >>>>> But for me, that does not imply one group give input to the other, because to me "input to" implies one group report to the other, which I do not think we do. >>>>> >>>>> Patrik >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg(a)icann.org >>>> https://mm.icann.org/mailman/listinfo/internal-cg

1 1

Re: [Area 1] [Internal-cg] ICANN52
by Kavouss Arasteh Feb. 13, 2015

Feb. 13, 2015

Dear Keith No it does not Report of CCWG work Stream 1 needs to be duly considered by ICG in a direct or indirect manner. Report of CCWG work stream 1 to ICANN may be rejected by ICANN thus if that report on accountability is not reached or considered by ICG the objectives specified by NTIA would not be met. By the way you may be in the same camp of the person that I referred to but you were not the one who said ICG need not any input from CCWG . It was someone else . Any way that statement to which you associate yourself is not correct Kavouss Sent from my iPhone > On 13 Feb 2015, at 18:48, Drazek, Keith <kdrazek(a)verisign.com> wrote: > > Hi Kavouss, > > I believe you are referring to my previous statements that the ICG is not expected to receive, incorporate or deliver a proposal from the CCWG Accountability. I stand by that statement. I did not say there would be no interaction or input exchanged among the various groups. > > Technically speaking, the CCWG Accountability will deliver its official report directly to the ICANN Board and not to the ICG. The ICG will only formally coordinate, consolidate and submit the proposals from the 3 operational communities, including from the CWG-Naming. The ICG and CCWG are currently on parallel tracks. > > Steve Crocker's new comment that the ICANN Board expects the ICG to "take into account the accountability mechanisms recommended by the CCWG" and that the CCWG and ICG proposals should be coordinated is not inconsistent with my statement. It is a clarifying remark that recognizes the two parallel tracks must be coordinated and informed by one another, and I believe it increases the importance of our work as ICG Liaisons to the CCWG. > > That said, I expect most of the CCWG and CWG coordination to take place directly between those two groups as has already begun. > > We will need to watch carefully for any potential conflicts, unnecessary duplication and gaps as the CCWG and CWG conduct their work. As Patrik has noted, "input" can and will be exchanged among the various groups, but does not mean submission and receipt of a formal proposal from the CCWG to the ICG. > > I hope this helps clarify the intent of my remarks. > > Regards, > Keith > > > On Feb 13, 2015, at 1:03 PM, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> wrote: > >> Dear Patrik >> Let us not play with words >> Someone in ICG clearly told that ICG does not expect any input from CCGG work stream 1 >> I did not agree to that statement now Milton very rightly remind all of us that there is a direct link between ICG and CCWG work stream 1 . >> Tks Kavouss >> >> >> Sent from my iPhone >> >> On 13 Feb 2015, at 10:38, Patrik Fältström <paf(a)frobbit.se> wrote: >> >>> >>>> On 13 feb 2015, at 09:15, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> wrote: >>>> >>>> 'ICG does not expect any input from CCWG .I did severely disagree with that statement but since no one else than me raised that issue I did not raise it again but in CCWG I mentioned that the sole purpose of Work Steam 1 was exactly to provide the accountability required to be in place or committed before transition is take place. >>> >>> My view: >>> >>> There is no contradiction between the two statements. It is all a question on what you mean by "input from". >>> >>> The ICG and CCWG are parallell, so none of the two groups report to each other. >>> >>> There is though [of course] a requirement that there is no contradiction between the two outputs. >>> >>> Because of that, coordination is needed. >>> >>> But for me, that does not imply one group give input to the other, because to me "input to" implies one group report to the other, which I do not think we do. >>> >>> Patrik >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg(a)icann.org >> https://mm.icann.org/mailman/listinfo/internal-cg

1 0