February 2015 - Ccwg-accountability1

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

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

Feb. 13, 2015

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 >

1 0

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

Feb. 13, 2015

Dear Milton, Thank you very much for your thoughtful and wise advice. I have raixsed this issue many times and every time I was told by somebody in ICG that for the sake of solidarity I do not name( please refer to my comments at several call and the corresponding transcript) but the answer that was given was. '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. See CCWG CHARTER, Once again sincere thanks to you in razing such a vital question Kavouss 2015-02-12 22:00 GMT+01:00 Milton L Mueller <mueller(a)syr.edu>: > The term “ready for implementation” needs to be subject to a lot of > critical scrutiny. > > On my way to an airport now but will give it more scrutiny soon. > > > > --MM > > > > *From:* internal-cg-bounces(a)icann.org [mailto: > internal-cg-bounces(a)icann.org] *On Behalf Of *WUKnoben > *Sent:* Thursday, February 12, 2015 11:10 AM > *To:* internal-cg(a)icann.org > *Subject:* [Internal-cg] ICANN52 > > > > Dear colleagues, > > > > my take from the ICANN52 meeting in Singapore re the IANA Stewardship > Transition and the future ICG related work: > > - see *statement from Steve Crocker*, ICANN Board Chair: > > << > > *We have received several questions requesting clarification as to how > ICANN will handle receipt of the proposal from the ICG and the Work Stream > 1 proposal from the CCWG. We hope the following will be helpful.* > > *NTIA is expecting coordinated proposals from both groups. They cannot > act on just one. Further, they expect the ICG proposal will take into > account the accountability mechanisms proposed by the CCWG. We are > heartened by the close coordination between the groups, including liaisons > from the ICG to the CCWG. ICANN is expecting to receive both proposals at > roughly the same time. When ICANN receives these proposals, we will > forward them promptly and without modification to NTIA. As we have > previously stated, if we do submit the proposals with an accompanying > communication of comments, they will be on points we had already shared > with the community during the development of the proposals.* > > *We therefore encourage the groups to continue coordinating closely to > ensure ICANN receives the proposals together and is able to provide them to > NTIA in a coordinated manner.* > > *With respect to improvements in our accountability, we are definitely > open to improvements*. > > >> > > > > He’s referring to the Names Community Proposal as an output from the > CWG-stewardship and the CCWG-accountability. > > Consequently the ICG would have to accomodate the overall timeline > accordingly. > > - *Larry Strickling, NTIA* Assistant Secretary, in a session on > Sunday, 09 Feb., pointed out that NTIA is expecting a common proposal from > the three communities (protocols, numbers, names). The proposal as a whole > should be ready for implementation. > > From this point of view I wonder whether the names and protocol > proposals delivered in the present version reach this level of readiness. > I’d like to suggest beginning a related ICG discussion about. this item and > the potential consequences. > > Best regards > > Wolf-Ulrich > > _______________________________________________ > Internal-cg mailing list > Internal-cg(a)icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > >

1 0