Thanks Greg. I added two comments to the ones you made on page 6. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: Tuesday, April 07, 2015 2:11 PM To: cwg-stewardship@icann.org Subject: [CWG-Stewardship] Fwd: [client com] Transition Models for Further Consideration My comments on the Sidley discussion draft are below. Greg ---------- Forwarded message ---------- From: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Date: Tue, Apr 7, 2015 at 2:07 AM Subject: Re: [client com] Transition Models for Further Consideration To: "Flanagan, Sharon" <sflanagan@sidley.com<mailto:sflanagan@sidley.com>> Cc: "cwg-client@icann.org<mailto:cwg-client@icann.org>" <cwg-client@icann.org<mailto:cwg-client@icann.org>> Sharon and All, Thank you for all your hard work. This is a very useful document. Here are my initial comments on the document: Page 5, Section I.A.4: The CWG needs to develop accountability mechanisms directly related to contract management and ICANN's behavior as a party. We can't shift this specific, tailored accountability responsibility to the CCWG. With ICANN (rather than "Contract Co.") entering into the contract, there is a danger of "the fox guarding the chicken coop" that needs to be controlled for. Page 6, Section 1.C.7(b): IRP should be defined the first time it occurs. Page 6, Section 1.D.2: The document states that "in the first instance, customers would seek to resolve issues directly with PTI and, only if unresolved, take the matter up to the CSC." This would be true of issues that individual customers were experiencing. However in the event of systemic issues (i.e., issues affecting many or all customers), I would expect that the CSC would be used to try and resolve issues in the first instance. [Chuck Gomes] It might be helpful to review the recommendations to be proposed by DT-M. A final version should be available this coming Friday. Page 6, Section 1.D.3: I did not expect that the CSC would be the "escalating party" for stakeholders at each level of escalation. Rather, I expected/thought that at some level, a multistakeholder body would step into the escalation process. One of the reasons the multistakeholder model works, in my opinion, is that different stakeholder groups, each representing the interests of their stakeholders, tend to balance each other out and bring about the need for compromise and consensus. The corollary of this is that each "uni-stakeholder" group tends to act like an "interested party" and act as an advocacy group (because it needs to do so and because it was created to do so). The danger is that in creating a "uni-stakeholder" group with operational responsibilities, like the CSC, it may still tend to act like an advocate for its constituents, rather than acting in the greater good. In other words, the CSC runs the risk of being "captured" at birth, by the "customers." Given the likely makeup of the CSC, oversight over the CSC, as a uni-stakeholder body without internal checks and balances, is critically important. [Chuck Gomes] Again I suggest looking at the recommendations to be proposed by DT-M. On a different note, I don’t think I share your concerns about the makeup of the CSC especially considering the limited decisions they would make. Page 7, Section E.1: The powers discussed here do not directly relate to oversight of the IANA Function. Instead, they focus entirely on oversight of the ICANN Board, which is not often directly involved in IANA matters. It's unclear how this "Multi-Stakeholder Community Organization" relates to our remit to deal with accountability for the IANA functions (but not general ICANN accountability). It's also unclear if this MSCO is the same as the "empowered Member Group" being created by the CCWG, or is a variation on or affiliate or subset of such empowered Member Group. Further, it is unclear whether this is the same thing as "statutory" members of ICANN or something different. Page 7-8, Section II,B & C: I think you should create a list of advantages and disadvantages of the Legal Separation Variant to parallel this list of advantages/disadvantages. It creates an odd imbalance to have this analysis of the Functional Separation Variant, but none for the Legal Separation Variant. Page 8, Section III.A.1(a): You state that an LLC "would not be a formally incorporated entity, but is a legally cognizable entity." While this is technically true, it may give the wrong impression. Specifically, although an LLC is not "formally incorporated," it is formally brought into being by filing formative documents with the state (very similar to a corporation). Thus the difference between "incorporation" and "formation." Page 9, Section III.A.2: In the "chapeau text," "alterative" should be "alternative." Page 11, Section III.D.4: You state that "if the SOs and ACs would themselves be ... designators of ICANN, they would need to form a legally cognizable entity." However, the SOs and ACs currently act as designators of the ICANN Board, and are not legally cognizable entities, to the best of my knowledge. Am I missing something? Page 11, Section III.E.1: These consequences of failure all seem fairly dramatic,and are some version of "firing" the offending party. Here, as elsewhere, I expect that actions short of firing would be more common. I would think that it is more likely that the consequence of most functional failures would be and agreed-to remedial action taken by PTI/IANA, likely with heightened oversight by ICANN/CSC/some multistakeholder thing. Page 12, Section III.F.3: You raise a question about the "fiduciary obligations" of the "person/body doing the compelling." Based on the prior sentence, this "person/body" would appear to be an independent arbitrator. I'm no expert on arbitration, but I would think that the duties (fiduciary or otherwise) of arbitrators are fairly well settled. Am I missing something? Page 14, Section IV.A.2: You state that "[a]n accountability mechanism for reviewing ICANN's policy-making decisions related to the IANA functions" is an area "of dependency and need for integration between CWG and CCWG. It's unclear whether you expect/think/recommend that this mechanism to be created by the CCWG (in which case it is likely to be a general purpose mechanism and not one specifically designed for IANA-related purposes) or the CWG. If it is the latter, we don't have any real work done to create such a mechanism. If it's the former, I'm not sure how much further ahead the CCWG is on such a mechanism, and I don't know whether a general purpose mechanism will be "fit for purpose" when it comes to reviewing IANA-related decisions. What do you think the path forward here is? I look forward to hearing from you and discussing this with you. I also look forward to the comments of my fellow CWG participants (which will be on the main email list for the CWG). Best regards, Greg On Sat, Apr 4, 2015 at 10:51 AM, Flanagan, Sharon <sflanagan@sidley.com<mailto:sflanagan@sidley.com>> wrote: Dear All, Attached is an initial discussion draft of the two models that the CWG requested Sidley’s input on: the internal accountability/hybrid model with two closely related variants: accountability mechanism with legal separation and accountability mechanism with functional separation. We look forward to discussing. Best regards, Sharon SHARON FLANAGAN Partner Sidley Austin LLP +1.415.772.1271<tel:%2B1.415.772.1271> sflanagan@sidley.com<mailto:sflanagan@sidley.com> **************************************************************************************************** This e-mail is sent by a law firm and may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. **************************************************************************************************** _______________________________________________ Cwg-client mailing list Cwg-client@icann.org<mailto:Cwg-client@icann.org> https://mm.icann.org/mailman/listinfo/cwg-client -- Gregory S. Shatan • Abelman Frayne & Schwab Partner | IP | Technology | Media | Internet 666 Third Avenue | New York, NY 10017-5621 Direct 212-885-9253<tel:212-885-9253> | Main 212-949-9022<tel:212-949-9022> Fax 212-949-9190<tel:212-949-9190> | Cell 917-816-6428<tel:917-816-6428> gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/> -- Gregory S. Shatan • Abelman Frayne & Schwab Partner | IP | Technology | Media | Internet 666 Third Avenue | New York, NY 10017-5621 Direct 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428 gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/>