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

[Guru Acharya]

Greg,

I think the internal-to-ICANN approach is extremely complicated when you
think of it in detail. The internal-to-ICANN approach would actually be
recommending two accountability mechanisms. The first mechanism for when
ICANN is the IANA operator. The second mechanism for when a non-ICANN
entity is the IANA operator. And these two accountability mechanisms will
have no similarity making transition between the two mechanisms a
logistical nightmare. In comparison, the current proposal of the CWG
envisions a seamless transition between the two scenarios.

Regards,
Guru

On Fri, Dec 12, 2014 at 12:16 PM, Greg Shatan <gregshatanipc at gmail.com>
wrote:

> I think Guru makes excellent points here and in his prior email.
>
> The CWG proposal has a very clear and implementable "exit path" for
> separability, and very little changes after separation, except for the
> identity of the IANA Functions Operator.
>
> By contrast, this proposal (and the related ALAC proposal) have a very
> uncertain and unknown "exit path" for separability, with many of the key
> decisions shipped off to the future for the MRT to decide, and the almost
> certain prospect of massive changes in the event of separation.
>
> These strike me as very essential infirmities in this proposal, for which
> I do not see apparent solutions.  Actually, I see one that resolves at
> least the "what happens next" problem, although not the "path to
> separation" problem.  The CWG draft proposal could be the separability
> solution for the internal-to-ICANN solution.  If ICANN screws up and
> performs so poorly and without regard to the interest of customers,
> stakeholders or the general public that the IANA functions must go
> elsewhere (and assuming that this rogue ICANN is nonetheless amicable to
> this separation due to some incredibly powerful but so far completely
> unknown accountability mechanisms), at that point the dust can be blown off
> the CWG proposal, and the right to the IANA Functions can be transferred to
> Contract Co., an IANA Functions Contract can be finished up and the
> proposed framework can be put into place at that time.  But that woudl
> require proponents of the internal-to-ICANN proposal to admit that the CWG
> proposal works just fine, and that their whole end game is enhancing ICANN
> accountability, not building a better mousetrap for transition of oversight
> and accountability for the IANA functions.  (A laudable goal, but
> completely out of our scope.)
>
> More fundamentally, why put off until tomorrow what we can do today?
>
> Greg
>
> *Gregory S. Shatan **|* *Abelman Frayne & Schwab*
>
> *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/>*
>
> On Fri, Dec 12, 2014 at 1:05 AM, Guru Acharya <gurcharya at gmail.com> wrote:
>>
>> Alan,
>>
>> I think it would be very short foresight if we refuse to play out the
>> most obvious not-so-stressful scenario for the internal to ICANN approach -
>> that MRT selects a new non-ICANN IANA operator. The 'We will leave it for
>> the future MRT to decide' nonchalance needs to factor in what options we
>> are leaving for MRT since this CWG is deciding the institutional
>> arrangement. The MRT's options will be limited by what we decide in this
>> CWG. If the internal-to-ICANN proposal is proposing that MRT doesn't have a
>> legal vehicle to contract, then how is it supposed to make the new
>> non-ICANN IANA operator accountable?
>>
>> Regards,
>> Guru
>>
>> On Fri, Dec 12, 2014 at 2:55 AM, Alan Greenberg <alan.greenberg at mcgill.ca
>> > wrote:
>>
>>>  At 11/12/2014 11:54 AM, Guru Acharya wrote:
>>>
>>> Hi Maarten,
>>>
>>> In the internal-to-ICANN approach that you suggest, I talk about the
>>> scenario that the MRT orders/requires ICANN to give up IANA. I assume ICANN
>>> peacefully agrees to give up IANA. The MRT would select a new IANA operator
>>> through the RFP process. In this case, would there would be a IANA
>>> Functions Contract between the new IANA Functions Operator and MRT (legal
>>> vehicle for MRT being ICANN)? Would ICANN be allowed to compete in the RFP
>>> in the next round? Everytime ICANN wins the RFP, there is an
>>> internal-to-ICANN approach and everytime ICANN loses the RFP, there is a
>>> external contract approach? I am understanding you correctly?
>>>
>>>
>>> I am not Maarten, but...
>>>
>>> I would see it more as a requirement by the MRT that ICANN divest itself
>>> of IANA, and would set the rules for selecting a new host.
>>>
>>> Alan
>>>
>>>
>>>
>>> Regards,
>>> Guru
>>>
>>> On Thu, Dec 11, 2014 at 10:09 PM, Maarten Simon <maarten.simon at sidn.nl>
>>> wrote:
>>>
>>> Hi Chuck,
>>>
>>>
>>>
>>> I like to respond with regard to your first comment: see below
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> Maarten
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: Gomes, Chuck [ mailto:cgomes at verisign.com <cgomes at verisign.com>]
>>> Sent: donderdag 11 december 2014 16:29
>>> To: Alan Greenberg; Greg Shatan; Maarten Simon
>>> Cc: cwg-stewardship at icann.org
>>> Subject: RE: [CWG-Stewardship] Strickling Remarks from 4 December re
>>> IANA Transition and Accountability
>>>
>>>
>>>
>>> Allan,
>>>
>>>
>>>
>>> I want to comment on a few of the points you make in the exchange below.
>>>
>>>
>>>
>>> 1.       “. . . the ICANN board has a rather powerful reason for being
>>> flexible and accomodating†.  Am I correct that that reason is the risk of
>>> losing the IANA functions?  If so, I would agree but I would also point out
>>> that for that risk to be real it seems to me that there must be some entity
>>> that could reassign those functions.  For now that is NTIA.  What would it
>>> be if NTIA goes away?
>>>
>>>
>>>
>>> MS: If the bylaws of ICANN would dictate so, the MRT could be given the
>>> authority to decide that ICANN has to give up the IANA function and hand it
>>> over to any new or existing structure MRT comes up with. The ICANN board
>>> (nor the community, nor the GAC) would not have any further say in this and
>>> ‘simply’ has to execute. This may sound unlikely but in fact works
>>> exactly the same as with the proposed Contract co. The board of the
>>> Contract co. will also have no say over the content of the contract, the
>>> contracted party or the term and termination of the contract and this will
>>> have to be arranged in its bylaws. If we seem to trust that the board of
>>> Contract co. will follow orders of the MRT (even in the far future) it is,
>>> I assume, because we think that we can find the legal measures to in the
>>> end if necessary force the board of Contract co. to do so. If that is
>>> possible within Contract co., and I guess we all count on that, I do not
>>> see why it than can’t be done (technically) within ICANN.
>>>
>>>
>>>
>>> 2.       “It is SO attractive to label ICANN as unchanging and
>>> inflexible, but current evidence does not bear that out.†  Can you share
>>> any cases where ICANN has been flexible about giving the Board the final
>>> say on a decision?
>>>
>>> 3.       “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†  I hope you are
>>> correct but I have serious doubts that that will happen unless there is a
>>> real risk of them losing the IANA functions and a refer back to 1 above.
>>>
>>>
>>>
>>> Chuck
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: cwg-stewardship-bounces at icann.org [
>>> mailto:cwg-stewardship-bounces at icann.org
>>> <cwg-stewardship-bounces at icann.org>] On Behalf Of Alan Greenberg
>>> Sent: Wednesday, December 10, 2014 9:32 PM
>>> To: Greg Shatan; Maarten Simon
>>> Cc: cwg-stewardship at icann.org
>>> Subject: Re: [CWG-Stewardship] Strickling Remarks from 4 December re
>>> IANA Transition and Accountability
>>>
>>>
>>>
>>> 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 boarard 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 accomodating.
>>>
>>> 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 be a good
>>> model. 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.
>>>
>>> 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.ICANN partially funded
>>> NetMundial, and completely different form of MS event and it did so without
>>> US government pressure.
>>>
>>> It is SO attractive to label ICANN as unchanging and inflexible, but
>>> current evidence does not bear that out.
>>>
>>>
>>> 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. And although you presume that the MRT would be wholly internal to
>>> ICANN, that is a premise in your mind, but not mine.
>>>
>>> Yes, without Contract Co, ICANN has the right to continue performing
>>> IANA functions. That provides a level of stability that the possibility of
>>> moving it (potentially every 5 years if some people have their way). But if
>>> the MRT can direct how that is done, that may not be so bad. And It is not
>>> inconceivable that the MRT could direct ICANN to divest itself of IANA in
>>> extreme situations.
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>> 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. 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. 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.
>>>
>>> Alan
>>>
>>>
>>> Greg
>>>
>>> Appreciate your response.
>>>
>>> Best,
>>>
>>> Maarten
>>>
>>> _______________________________________________
>>> CWG-Stewardship mailing list
>>>  CWG-Stewardship at icann.org
>>>  https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141212/8f1573e9/attachment-0001.html>