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

[Greg Shatan]

On Thu, Dec 11, 2014 at 6:40 AM, Alan Greenberg <alan.greenberg at mcgill.ca>
wrote:
>
> 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.
>

GS: I'm still somewhat unclear.  IANA is internal to ICANN in the CWG
proposal as well, in the sense that ICANN will be performing the IANA
Functions post-transition.  I suppose the difference is that, in the CWG
proposal, the ultimate right to perform the IANA functions rests with
Contract Co., while in your proposal, the ultimate right to perform the
IANA Function is an ICANN asset.

I will be curious to see what other parts of your proposal are "internal to
ICANN" in contrast with the CWG proposal.

Greg

> --
> 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/20141212/90d5d031/attachment-0001.html>