[client com] Transition Models for Further Consideration

Tue Apr 7 06:07:27 UTC 2015

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.

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.

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>
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
> 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
> 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 *| **Main* 212-949-9022

*Fax*  212-949-9190 *|* *Cell *917-816-6428

*gsshatan at lawabel.com <gsshatan at lawabel.com>*

*ICANN-related: gregshatanipc at gmail.com <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-client/attachments/20150407/7ce49bfe/attachment-0001.html>