[CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability
Alan Greenberg
alan.greenberg at mcgill.ca
Thu Dec 11 21:25:31 UTC 2014
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>
More information about the CWG-Stewardship
mailing list