[CWG-Stewardship] Fwd: [client com] Transition Models for Further Consideration

Tue Apr 7 22:04:12 UTC 2015

Thanks Greg.  I added two comments to the ones you made on page 6.

Chuck

From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Greg Shatan
Sent: Tuesday, April 07, 2015 2:11 PM
To: cwg-stewardship at 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 at gmail.com<mailto:gregshatanipc at gmail.com>>
Date: Tue, Apr 7, 2015 at 2:07 AM
Subject: Re: [client com] Transition Models for Further Consideration
To: "Flanagan, Sharon" <sflanagan at sidley.com<mailto:sflanagan at sidley.com>>
Cc: "cwg-client at icann.org<mailto:cwg-client at icann.org>" <cwg-client at icann.org<mailto:cwg-client at 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 at sidley.com<mailto:sflanagan at 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 at sidley.com<mailto:sflanagan at 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 at icann.org<mailto:Cwg-client at 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 at lawabel.com<mailto:gsshatan at lawabel.com>

ICANN-related: gregshatanipc at gmail.com<mailto:gregshatanipc at 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 at lawabel.com<mailto:gsshatan at lawabel.com>

ICANN-related: gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>

www.lawabel.com<http://www.lawabel.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150407/e6706578/attachment-0001.html>