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

[Alan Greenberg]

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 
><<mailto:maarten.simon at sidn.nl>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]
>Sent: donderdag 11 december 2014 16:29
>To: Alan Greenberg; Greg Shatan; Maarten Simon
>Cc: <mailto:cwg-stewardship at icann.org>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: 
><mailto:cwg-stewardship-bounces at icann.org>cwg-stewardship-bounces at icann.org 
>[mailto: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: <mailto:cwg-stewardship at icann.org>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 
><<mailto:maarten.simon at sidn.nl>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
><mailto:CWG-Stewardship at icann.org>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/20141211/2c624eb2/attachment-0001.html>