[CCWG-ACCT] Thinking ahead - overcoming the legal obstacles to accountability

Wed Feb 18 00:09:43 UTC 2015

Phil,

I don't think we have time for an RFP process, nor do I think one is
necessary. In my experience, only a small percentage of legal engagements
come via an RFP process.  The process is already underway.  We have been
putting together criteria for the right lawyer/firm, and coordinating
between the CWG and the CCWG.  We have also been making inquiries and doing
research to identify "best of breed" firms in the substantive areas we
require.

Given that many of the accountability remedies and stress tests pose issues
under California law, getting far away from California would be
ill-advised, since we need expertise in California law.  If there are
conflicts, they will be identified in the process.  If there are no
conflicts, I don't think that being located in the State of California will
create any issues for independence (ICANN is not a behemoth, like, e.g.,
General Motors in Detroit in the 1950's).  Likely, any firm we choose will
have offices in California and a number of other places (inside and outside
the U.S.).

Please note I'm speaking for myself and not for others involved in the
lawyer-finding process (though I believe they will likely agree with me).

Greg

On Tue, Feb 17, 2015 at 6:17 PM, Phil Buckingham <phil at dotadvice.co.uk>
wrote:

> Thanks Greg for the clarity of explanation to a UK based non lawyer.
>
>
>
> Absolutely, I agree. It should  be up to the WG to select the appropriate
> law firm with the CCWG- Accountability as its client with ICANN picking up
> the tab.
>
>
>
> When and how does the WG put together the criteria for a RFP ?  I would
> thought the “said law firm counsel “needs  to as far removed from the State
> of California as possible  - to ensure complete independence and any
> potential conflicts of interest.
>
>
>
> Regards,
>
>
>
> Phil
>
>
>
> *From:* accountability-cross-community-bounces at icann.org [mailto:
> accountability-cross-community-bounces at icann.org] *On Behalf Of *Phil
> Corwin
> *Sent:* 17 February 2015 22:08
> *To:* Edward Morris; Greg Shatan
>
> *Cc:* Accountability Cross Community
> *Subject:* Re: [CCWG-ACCT] Thinking ahead - overcoming the legal
> obstacles to accountability
>
>
>
> Agreed.
>
>
>
> It would be remiss not to take available ICANN funds to hire qualified and
> expert counsel on these important questions. Those funds have been derived
> from the community, primarily in the form of registrant fees upstreamed
> through contracted parties.
>
>
>
> As Greg observed, so long as the WG has the autonomy to select the law
> firm and the WG and not ICANN is its client, the advice it renders will be
> independent of ICANN’s views and corporate interest.
>
>
>
> *Philip S. Corwin, Founding Principal*
>
> *Virtualaw LLC*
>
> *1155 F Street, NW*
>
> *Suite 1050*
>
> *Washington, DC 20004*
>
> *202-559-8597 <202-559-8597>/Direct*
>
> *202-559-8750 <202-559-8750>/Fax*
>
> *202-255-6172 <202-255-6172>/cell*
>
>
>
> *Twitter: @VlawDC*
>
>
>
> *"Luck is the residue of design" -- Branch Rickey*
>
>
>
> *From:* accountability-cross-community-bounces at icann.org
> [mailto:accountability-cross-community-bounces at icann.org] *On Behalf Of *Edward
> Morris
> *Sent:* Tuesday, February 17, 2015 5:03 PM
> *To:* Greg Shatan
> *Cc:* Accountability Cross Community
> *Subject:* Re: [CCWG-ACCT] Thinking ahead - overcoming the legal
> obstacles to accountability
>
>
>
> Excellent explanation of a component of American legal practice that
> non-Americans or non-lawyers may not be familiar with. Thank you very much
> Greg.
>
>
>
> Sent from my iPad
>
>
> On Feb 17, 2015, at 9:58 PM, Greg Shatan <gregshatanipc at gmail.com> wrote:
>
> Kieren,
>
>
>
> I don't think it is foolish at all to have ICANN pay for the independent
> advice.  It is not uncommon for one party to pay the bill and for another
> party to be the client.  It's not even uncommon to have a board committee
> of a corporation hire independent counsel where the committee's interests
> are divergent from the corporation (e.g., when dealing with an internal
> investigation) and have the corporation pay.  These are situations that law
> firms are comfortable handling.  Basically, the question is "who is the
> client?" and the client would be the Working Group(s), not ICANN.  The law
> firm's ethical "duty of loyalty" is to the client, not the entity paying
> the bills.  Given that these ethical rules are in fact taken very seriously
> and that these are all firms that likely have over $1 billion in revenues,
> the temptation to "cheat" and be ICANN-friendly would be basically
> non-existent.
>
>
>
> What would be foolish would be to fail to set up the relationship between
> the firm and the Working Group(s) in the ways needed to maintain
> "independence." and/or to then fail to govern ourselves (and for ICANN to
> govern itself) in a way that preserves that independence.  That would be a
> huge waste of time, money and effort, likely set back transition schedules,
> and send a terrible message regarding ICANN's accountability and
> self-control.
>
>
>
>
>
> Greg
>
>
>
> On Tue, Feb 17, 2015 at 4:42 PM, Kieren McCarthy <
> kieren at kierenmccarthy.com> wrote:
>
> > May I suggest that we express our emotions using more friendly words (!
> foolish).
>
>
>
> I'm not sure why the use of "foolish" concerns you so much, Seun. I think
> it *is* foolish to allow ICANN to pay for independent advice that we would
> expect to contradict its own legal advice and on a topic of supreme
> importance to the organization.
>
>
>
> I could say "ill advised" or "unwise" or "incautious" but that would be
> fake diplomacy on my part. I mean "foolish". I wouldn't use, say, "idiotic"
> or "stupid" because they would imply people here are not intelligent when
> they clearly are. But even very smart people can be foolish.
>
>
>
>
>
>
>
> Kieren
>
>
>
>
>
> On Tue, Feb 17, 2015 at 11:54 AM, Seun Ojedeji <seun.ojedeji at gmail.com>
> wrote:
>
> Hi Kieren,
>
> May I suggest that we express our emotions using more friendly words (!
> foolish). That said, I think you raised good point; issue 2 seem to be a
> stress test case of issue 1 and I would suggest it is added to the existing
> list of stress test scenarios.
>
> From what I gathered so far ( including from ICANN 52), this process seem
> to be beyond business as usual, Especially as we heard the board confirm it
> won't alter the outcome of this process when presenting to NTIA.
>
> One other thing that may be important though is to ensure  implementation
> is a perquisite to transition [which i fear will also further confirm the
> reality of !transition by Sept :( ]
>
> Cheers!
>
> sent from Google nexus 4
> kindly excuse brevity and typos.
>
> On 17 Feb 2015 20:13, "Kieren McCarthy" <kieren at kierenmccarthy.com> wrote:
>
> Hello all,
>
>
>
> There have been no less than seven previous attempts to introduce real
> accountability at ICANN. They have all failed to achieve a fundamental
> goal: override or impact ICANN corporate (under whatever circumstances).
>
>
>
> In the specific cases where the override recommendations have been
> explicit, they have been undermined at the last step by ICANN internal
> legal advice.
>
>
>
> This group has, to some degree, learned from the past by deciding that it
> needs to get independent legal advice for its recommendations as part of
> the process.
>
>
>
> Even more usefully, ICANN's legal team has been prompted into providing
> its own legal analysis so we know what its position is ahead of time.
>
>
>
> Aside from the fact that I think allowing ICANN to pay for the external
> independent legal advice is foolish in the extreme, I see two fundamental
> issues for this group to discuss and reach agreement on if this process is
> to have the desired end result.
>
>
>
> And they are:
>
>
>
> 1. What happens if/when the independent legal advice say a particular
> mechanism is perfectly legal but ICANN's internal legal advice say it isn't?
>
>
>
> What will Board members do? How do we ensure this discussion happens
> publicly and with plenty of time remaining?
>
>
>
> I think we should ask Board members now what they would do. Would they be
> willing to override internal legal advice, and under what circumstances?
> Will they commit to some kind of binding arbitration in the event that the
> two legal advices conflict in fundamentally important ways?
>
>
>
> This is an almost inevitable scenario so let's get ahead of it now and
> make reasoned decisions before the pressure and politics come into play.
> Plan ahead.
>
>
>
>
>
> 2. A fundamentally piece of the accountability mechanisms that are likely
> to be recommended includes making ICANN a member organization of some type.
>
>
>
> We have Jones Day on record as saying that don't think California law
> allows anyone but the Board to make final decisions (in fact, they don't
> actually say that if you read it carefully because they know it's not true).
>
>
>
> What we don't have is Jones Day/ICANN on record talking about the other
> legal get-out clause they have used in the past when it comes to
> accountability: anti-trust law.
>
>
>
> ICANN's particular interpretation of anti-trust law has been pulled out as
> a final defense multiple times but I haven't seen it yet in this latest
> round of accountability discussions, so it is more than possible that it is
> holding back that particular defense now that the "California law corporate
> code" genie is out of the bottle.
>
>
>
> I can easily see a scenario where we all agree that it is possible to make
> these changes under California corporate law and then agree to hand over
> IANA to ICANN only to find that the Board discovers at the last minute that
> they also violate anti-trust law and so, regretfully, cannot be
> implemented.
>
>
>
> So I would ask this group to try to get ICANN's formal position on
> anti-trust law with respect to possible changes and also get independent
> legal advice on that aspect too.
>
>
>
> I would also recommend that people go through previous failures to
> introduce recommendations and try to find what the legal justifications
> were that prevented them from being implemented. And then do the same
> pre-emptive work so we don't end up repeating history.
>
>
>
> Hope this is useful.
>
>
>
>
>
>
>
> Kieren
>
>
>
>
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
>
>
>
> --
>
> *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/>*
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.5646 / Virus Database: 4284/9131 - Release Date: 02/17/15
>

-- 

*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/accountability-cross-community/attachments/20150217/18e6979a/attachment.html>