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@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com> * *www.lawabel.com <http://www.lawabel.com/>* On Fri, Dec 12, 2014 at 1:05 AM, Guru Acharya <gurcharya@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@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@sidn.nl> wrote:

Hi Chuck,

I like to respond with regard to your first comment: see below

Best,

Maarten

From: Gomes, Chuck [ mailto:cgomes@verisign.com <cgomes@verisign.com>] Sent: donderdag 11 december 2014 16:29 To: Alan Greenberg; Greg Shatan; Maarten Simon Cc: cwg-stewardship@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@icann.org [ mailto:cwg-stewardship-bounces@icann.org <cwg-stewardship-bounces@icann.org>] On Behalf Of Alan Greenberg Sent: Wednesday, December 10, 2014 9:32 PM To: Greg Shatan; Maarten Simon Cc: cwg-stewardship@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@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@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship

Hi Greg, See my remarks inline below. Best, Maarten From: Greg Shatan [mailto:gregshatanipc@gmail.com] Sent: vrijdag 12 december 2014 7:46 To: Guru Acharya Cc: Alan Greenberg; Maarten Simon; Gomes, Chuck; cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability 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. MS: I am not sure about the ‘very little changes after separation’ part. Apart from the actual transition from ICANN to a third party that you will have in any form of separation, I suspect that much more will happen than a simple transfer of the existing agreement. Separation is the moment for anyone in the community (read: the entire world) to start discussions about who will be the new IANA service provider, on what terms and probably also if this is the correct model and even the question if the multistakeholder model does function or not. It is not the retendering of an ordinary commercial contract but – at least seen by many – as one of the most essential global public internet services. 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. MS: As stated earlier, I support the idea of predefined exit path but, as we do not know what the situation will be at the time this will actually be needed (and the whole idea of the internal to ICANN approach is the hope that this will never be needed) I suggested that the MRT should have the freedom at that point of time to decide to find another solution. 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) MS: Sorry Greg, but these ‘so far completely unknown accountability mechanisms‘ are as completely unknown as the similar accountability mechanisms that have to be put in place in the bylaws of Contract co. to make sure that the board of Contract co. under all circumstances follows orders of MRT. Yes, it will be much easier to arrange this in a newly to be formed entity than in an existing already complicated ICANN but in a legal technical sense the differences seem minor to me. , 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? MS: because I am not so sure that we fill find a for everyone acceptable solution for some of the outstanding issues with regard to Contract Co. (i.e. jurisdiction (maybe the US is also not to such a good idea because of its ‘claim culture’), be safe from liability and other legal claims (like a seizure of .ir), the financing issue). In the internal-to-ICANN version these issues are more easily solved (or simply do not exist). 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@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/> On Fri, Dec 12, 2014 at 1:05 AM, Guru Acharya <gurcharya@gmail.com<mailto:gurcharya@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@mcgill.ca<mailto:alan.greenberg@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@sidn.nl<mailto:maarten.simon@sidn.nl>> wrote: Hi Chuck, I like to respond with regard to your first comment: see below Best, Maarten From: Gomes, Chuck [ mailto:cgomes@verisign.com] Sent: donderdag 11 december 2014 16:29 To: Alan Greenberg; Greg Shatan; Maarten Simon Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@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@icann.org<mailto:cwg-stewardship-bounces@icann.org> [ mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Wednesday, December 10, 2014 9:32 PM To: Greg Shatan; Maarten Simon Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@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@sidn.nl<mailto:maarten.simon@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@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship