[CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability

[Alan Greenberg]

Just to be clear for future communications, our use of "INTERNAL - TO - ICANN" means that IANA is internal, not the other component such as the MRT or equivalent.
-- 
Sent from my mobile. Please excuse brevity and typos.

On December 11, 2014 1:28:40 AM EST, Greg Shatan <gregshatanipc at gmail.com> wrote:
>My responses are inline below.
>
>Greg
>
>
>On Wed, Dec 10, 2014 at 9:32 PM, Alan Greenberg
><alan.greenberg at mcgill.ca>
>wrote:
>
>>  At 10/12/2014 02:53 PM, Greg Shatan wrote:
>>
>> Maarten:
>>
>> My answers are inline below.
>>
>> Greg
>>
>> On Mon, Dec 8, 2014 at 5:46 PM, Maarten Simon <maarten.simon at sidn.nl>
>> wrote:
>>
>> Hi Greg,
>>
>> Although I personally have not made up my mind as yet if the contract
>co
>> or an internal ICANN solution is preferable, I have posted a very
>rough
>> idea for an internal solution  in another thread that I have not seen
>your
>> response to. I repeat it here as I am interested to here from you if
>you
>> think it would be legally possible (apart from the fact that you
>probably
>> do not support it for other reasons):
>>
>> “If we could arrange via the bylaws that the ICANN board explicitly
>has
>> to follow orders from a MRT-like structure,
>>
>> GS:  This is a pretty big "if."  Unlike Contract Co., which would be
>built
>> from the ground up to be a corporation with very limited purpose and
>goals
>> and limitations upon its directors and officer, and thus lends itself
>to
>> this "following orders" model, ICANN is an existing organization with
>a
>> large board and officer group and many activities. At best, this type
>of
>> organization does not lend itself to such a model.  At worst, it's
>not even
>> possible.  But let's assume, solely for the sake of argument, that
>the
>> ICANN bylaws can be modified in this fashion.  I am assuming that the
>MRT
>> will be "internal-to-ICANN" like the current SOs and ACs (and in
>contrast
>> to the ICG).  Is that correct?  If so, how do you involve the global
>> multistakeholder community (beyond ICANN) as required by the NTIA?
>>
>>
>> AG:
>> I will no doubt echo some of what Olivier has said, despite Milton
>having
>> explained that he is wrong.
>>
>> Yes, it is more difficult to retrofit such measures into the existing
>> ICANN, but then the ICANN board has a rather powerful reason for
>being
>> flexible and accommodating.
>>
>
>GSS: We need more than powerful reasons -- we need accountability and
>enforceability.  Relying on ICANN to stay motivated is not enough.  If
>we
>could rely on people and organization to stick to their word or their
>position regardless of changing motivations and attitudes, we wouldn't
>need
>contracts or lawyers or courts.  When things are going well between two
>parties, the contract can more or less just stay in a drawer.  It's
>when
>things fall apart that a contract -- an enforceable contract -- becomes
>necessary.
>
>>
>> It is not clear how "internal" an MRT would be. It would be organized
>> under the auspices of ICANN. Whether it "reports" to ICANN is
>something
>> else altogether. The relationship between the IETF and ISOC might
>serve as
>> an example.  ISOC provides funding and perhaps legal protection but I
>don't
>> think that we could say that the IETF is internal to ISOC or
>controlled by
>> it.
>>
>
>GSS:  My main concern here is that you state that the MRT in an
>"internal-to-ICANN" proposal would be "organized under the auspices of
>ICANN."  This raises serious concerns regarding its independence,
>although
>"auspices" is an ambiguous word.  If you think that the ICG is
>organized
>"under the auspices of ICANN," I have less problem with your
>characterization (but note Q3 in the ICG's FAQ, which I cited in my
>addition to Milton's response to Olivier.
>
>>
>> The ICG and the Stewardship CWG have representation from outside of
>ICANN.
>> Yes, Milton points out that they were created due to pressure and
>> conditions set by the NTIA. As above, the desire to retain IAINA is a
>> mighty big carrot to continue the tradition.
>>
>
>GSS: Sometimes you need a carrot.  Sometimes you need a stick --
>because
>you can't always rely on carrots.  After all, Teddy Roosevelt did not
>say
>"Speak softly and carry a big carrot."  He said "Speak softly and carry
>a
>big stick."  There's a reason for this.
>
>
>> ICANN partially funded NetMundial, and completely different form of
>MS
>> event and it did so without US government pressure.
>>
>
>GSS: And then it partially funded the NetMundial Initiative....
>
>>
>>
>> It is SO attractive to label ICANN as unchanging and inflexible, but
>> current evidence does not bear that out.
>>
>
>GSS: I actually am not in the "ICANN-bashing" camp.  But I do have deep
>concerns about continuing tendencies of ICANN-the-corporation,
>particularly
>its tendency to get out ahead of the community (and its not really "out
>ahead," since the direction is usually divergent from the community
>when it
>gets out ahead) and to think of itself too much as just another
>not-for-profit corporation, rather than the steward of a
>multistakeholder
>governance ecosystem.
>
>>  we might not need a contract but have an (internal) MoU/SLA or
>whatever.
>>
>> GS:  There really is no such thing as an internal MoU/SLA.  Both of
>these
>> are agreements (just like the IANA Functions Contract), and need to
>be made
>> between two or more legal entities capable of contracting.  If the
>MRT-like
>> structure is internal to ICANN, it can't have a contract with ICANN
>-- that
>> would be ICANN contracting with itself.  The "whatever" would have to
>be an
>> internal document of a non-contractual/non-agreement nature. 
>Conceivably,
>> it could be a policy.  If it is a policy, it would most likely have
>to go
>> through an ICANN Policy Development Process.  Would this be done
>separately
>> by the ccNSO and the GNSO under their separate PDP guidelines?  Or
>would we
>> try to put together a joint PDP Working Group?  And how long would
>this PDP
>> take to develop an "IANA Functions Policy"?
>>
>> The other thing the IANA Functions Contract establishes is that the
>right
>> to run the IANA Functions ultimately resides in Contract Co.  ICANN's
>right
>> to do it is purely contractual; essentially, ICANN is a licensee, and
>the
>> MRT is a a licensor.  Under this scenario, the current IANA Contract
>goes
>> away, and ICANN is left holding the right to perform the IANA
>Functions.
>> This means that the IANA Functions are now an inherent right of ICANN
>> This is a very different overall set-up, with different consequences.
>> Losing a right one has by contract is a very common problem, and is
>as old
>> as contracts.  Losing an inherent right and sector of services
>because a
>> committee says that you have failed to live up to internal policies
>is both
>> very uncommon and very novel, creating considerable uncertainty even
>if it
>> is a technical possibility.
>>
>>
>> AG:
>> I have no clue as to the legal issues involved, but apparently ICANN
>can
>> sign a MoU with an internal body. The relationship between ICANN and
>the
>> At-Large regional At-large Organizations (RALOs) are established
>through
>> MoUs.
>>
>
>GSS: It's very nice that these are called MoU's.  But if these are
>between
>ICANN and an internal body, these are not enforceable contracts, so
>ICANN
>is not legally obligated or bound by these "MoUs".  Has anyone taken
>one of
>these MoU's to court and tried to enforce it against ICANN?  I suppose
>we
>can rely on the pressure of the community to discipline ICANN -- but
>that
>makes me uneasy.  In the past, if the pressure of the community failed,
>there was always the NTIA and the IANA Contract to provide the "stick."
> With that gone, much of the leverage of the community would be gone as
>well -- hence this exercise and the parallel task of
>CCWG-Accountability.
>
>
>
>> And although you presume that the MRT would be wholly internal to
>ICANN,
>> that is a premise in your mind, but not mine.
>>
>
>I assumed this because I had only a five-line paragraph to go on, and I
>thought we were discussing an "internal to ICANN" proposal.  It seemed
>like
>the right assumption under the circumstances
>
>>
>> Yes, without Contract Co, ICANN has the right to continue performing
>IANA
>> functions.
>>
>
>GSS:  In reality, in this model ICANN doesn't merely have the right to
>continue performing IANA functions.  It *owns* the IANA Functions.
>
>
>> That provides a level of stability that the possibility of moving it
>> (potentially every 5 years if some people have their way).
>>
>
>GSS: I don't think that having contracts of limited duration is an
>indicator of lack of stability.  I have seen licensing relationships go
>on
>for decades using a series of contracts of limited duration.  What it
>does
>do is keep the licensee on its toes.  A perpetual arrangement removes a
>certain amount of healthy motivation to perform and innovate.
>
>
>> But if the MRT can direct how that is done, that may not be so bad.
>And It
>> is not inconceivable
>>
>
>GSS: We are back to the "ifs" and "not inconceivables."  I've dealt
>with
>these in my original reply.
>
>> that the MRT could direct ICANN to divest itself of IANA in extreme
>> situations.
>>
>> GSS: It might not be inconceivable, but it's pretty close.
>
>>
>>  If the ICANN board would at a certain moment in time still decide
>not to
>> follow orders of the MRT, I would assume it may be sued by affected
>parties
>> for violating its own bylaws.
>>
>> GS: Litigation should be a last resort, not a first resort, when it
>comes
>> to enforcement.  Contract Co. can terminate the contract (or decide
>not to
>> sign another one when it expires). The MRT has no such ability.  That
>is
>> why you are suggesting litigation -- which is not an
>"internal-to-ICANN"
>> solution at all.  In addition to not being "internal-to-ICANN,"
>litigation
>> (in any jurisdiction) is expensive, lengthy and consumes great time
>and
>> resources, and may not produce a result in any kind of useful
>timeframe.
>> In any event, who are the "affected parties" that would sue?  Is it
>only
>> one registry, or is it many?  What if it's a stakeholder group, such
>as
>> "civil society"?  If there are many litigants, they would need to
>enter
>> into some sort of joint litigation agreement, form a coordinating
>group and
>> deal with a whole host of other things.  And not every affected party
>has a
>> litigation war chest to go up against ICANN -- unlike Contract Co.,
>which
>> will be indemnified. I don't think there's any way that ICANN would
>agree
>> to indemnify, defend and hold harmless every "affected party" that
>might
>> challenge a decision relating to IANA Functions.  So, litigation
>funding
>> would be a very real issue.
>>
>> Finally, I'm not at all sure that the "affected parties" will have
>the
>> standing to sue ICANN for violating its bylaws.  This might be a
>right that
>> a shareholder would have if ICANN had shareholders (but nonprofits
>don't
>> have shareholders).  Third parties may not have a cause of action
>here on
>> that front, and would need to find some other theory that supports a
>> lawsuit.  By contrast, breach of contract litigation is fairly
>> straightforward (not that I'm supporting litigation before other
>forms of
>> escalation are exhausted).
>>
>>  We further may dictate in the bylaws that ICANN has to give up the
>IANA
>> function if decided by this MRT and of course seal it by dictating
>that
>> these specific articles may only be changed with the explicit consent
>of
>> the MRT.â€
>>
>> GS: Again, I'm not at all sure we can dictate in the bylaws that
>ICANN has
>> to "give up the IANA function if decided by the MRT."  (By contrast,
>it's
>> quite clear that ICANN can enter into enforceable obligation if it
>signs an
>> agreement with a third party.) But again, let's assume it for the
>sake of
>> argument.  In your scenario, it is implicit that the right to perform
>the
>> IANA Functions is an inherent right of ICANN, not a right granted to
>it by
>> a third party.  So instead of Contract Co. terminating an agreement,
>we
>> have the ICANN Board being instructed to cause ICANN to cease part of
>its
>> services.  I am much more skeptical that this is a realistic
>assumption,
>> especially since it could run counter to the fiduciary duty of the
>> Directors to ICANN.  (By contrast, I don't see the MRT instructing
>Contract
>> Co. to do something counter to Contract Co.'s interests, given the
>limited
>> scope and purpose of Contract Co.)  But let's go on.  The concept of
>ICANN
>> "giving up" the IANA functions is quite nebulous.  Since it's an
>inherent
>> right of ICANN's, ICANN would have to run the RFP to find the next
>IANA
>> Functions Operator.  Are you assuming that the MRT will do this as
>well,
>> rather than ICANN? That seems like another big assumption.  And what
>> exactly would ICANN be transferring?  If it is an asset of ICANN, it
>may
>> expect compensation for it (indeed there could be fiduciary duty
>issues if
>> the Board "gives it away."
>>
>> Also, once the IANA Functions are transferred away from ICANN, how
>will
>> oversight and accountability continue (since all of the oversight and
>> accountability is "internal-to-ICANN") -- this seems like quite a big
>issue
>> in terms of "separability," actually.  Will the new IANA be required
>by the
>> RFP to amend its bylaws and replicate the MRT and the CSC and the IAP
>(and
>> the IRB) to match the current set-up?
>>
>> Another big difference (and I think a disadvantage) is that there is
>no
>> periodic expiration of the IANA Contract, with the implicit or
>explicit
>> promise of an RFP or at least a re-examination of the terms of the
>> agreement.  In essence, this now becomes ICANN's right in perpetuity,
>> unless it fails to properly perform the IANA Functions in a very
>> significant and ongoing way.
>>
>> Finally, while there are ways to limit bylaw changes that i am aware
>of
>> under US law (e.g., supermajority voting combined with board
>structuring),
>> I really don't think that this power can be put into the hands of the
>MRT
>> without a host of other governance changes to ICANN.  Of course,
>without
>> research I can't be sure, and it may be that some significant
>reworking of
>> ICANN's overall Board and governance structure could elicit this
>result.
>> But that would require further research and consideration.
>>
>> Overall, this seems a lot more complex and uncertain than the set-up
>in
>> the Draft Proposal.  This also does not deal with operational aspects
>of
>> replacing NTIA.  In addition to an MRT-like structure, are you also
>> assuming a CSC-like structure to provide basic operational oversight
>of the
>> IANA Functions and an Appeals Panel for disputes regarding how the
>IANA
>> Functions are carried out?  If so, there's no real advantage in terms
>of
>> the level of complexity (and probably a disadvantage, at that).  In
>any
>> event, any proposal has to deal with more than just separability.
>>
>>
>> AG:
>> Perhaps it is time for us to stop talking about what we think might
>not be
>> possible (as the above paragraphs do several times) and get some
>facts.
>>
>> ICANN regularly accepts the concept that an external body can tell it
>> exactly what to do - many of its contracts specify binding
>arbitration
>> which leave the ICANN Board with no wriggle room. ICANN considers
>this
>> preferable to litigation, and it accepts the consequences that it
>will be
>> bound to honour what an external party dictates.
>>
>
>GSS: I have never said that ICANN would not accept the concept that an
>external body can't tell ICANN exactly what to do.  As a matter of
>fact,
>that is exactly the reason why the CWG Draft Proposal has an external
>body
>-- Contract Co. -- with the power to tell ICANN exactly what to do --
>by
>using an enforceable contract with an external party.
>
>As for the difference between arbitration and litigation -- they are
>really
>just two flavors from the same ice cream truck.  Some people think
>arbitration is faster and cheaper than litigation -- many who have been
>involved in arbitrations will spit up their lunch if you tell them
>that.
>An arbitral body is not merely an 'external body" -- it is a body that
>the
>parties have agreed in a binding agreement will be vested with
>essentially
>all the powers of a court, except that it is private.  And the ability
>to
>keep arbitrations private is probably the only difference with
>litigation
>that is always true.
>
>>
>> I actually have faith that the Accountability CCWG can come up with
>> effective accountability measures that ICANN will be obliged to
>accept if
>> it is exchange for keeping the IANA function.
>>
>> GSS:  Accountability with regard to ICANN's performance of the IANA
>> functions is out of the CCWG's scope and in our scope to deal with
>it.  I
>> can't sit here and say "the CCWG will provide." Also, I think you are
>> changing the essential bargain inherent in the "Stream 1" concept --
>ICANN
>> is obliged to accept effective accountability measures so that the
>> transition can go forward -- not so that ICANN can be granted
>ownership of
>> the IANA function.
>>
>>  I know it is (still) very rough and I directly agree that separating
>the
>> IANA function will in a legal sense probably be a lot more difficult,
>I
>> think it would be possible under my legal system at home.
>>
>> GS:  I am not sure that this is impossible, but there are a number of
>very
>> fundamental "ifs" and assumptions here that seem to make this
>speculative
>> and uncertain in the extreme, with no virtue other than to be
>> "internal-to-ICANN."  I also don't see the advantages of this set-up,
>but
>> perhaps I am missing something.
>>
>>
>> AG:
>> Then we agree to disagree. I see stability, working with a known
>entity,
>> lower costs (potentially a LOT lower) and not adding significant
>complexity
>> and processes as being a large benefit.
>>
>
>GSS: I see just as much complexity in the internal to ICANN concept, if
>not
>more.
>
>
>> I see not having to deal with lawsuits over failed RFP bids to take
>the
>> IANA contract as a benefit (in many cases, suing after a failed bid
>is
>> almost automatic.
>>
>
>GSS: This is just a bogeyman, with nothing but sheer speculation and
>fearmongering going for it.  And if post-RFP suits are as common as you
>presume them to be (a presumption I deem incorrect), they would be just
>as
>likely in the event of an RFP when the internal-to-ICANN arrangement
>fell
>apart and ICANN was forced to divest itself of ICANN by RFP (assuming
>this
>can even happen, about which I remain skeptical in the extreme..)
>
>
>> I value a higher degree of certainty that the three core IANA
>functions
>> will stay together instead of being fractured as the result of
>mandatory
>> RFPs. I could go on.
>>
>
>GSS: I am not necessarily in favor of mandatory RFPs (which is not part
>of
>the CWG proposal at this time).  I like certainty, too, but I am not
>willing to trade away accountability, enforceability and separabiity in
>order to get it.
>
>Greg
>
>>
>> Alan
>>
>>
>> Greg
>>
>> Appreciate your response.
>>
>> Best,
>>
>> Maarten
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141211/ad78991f/attachment-0001.html>