There is no doubt there are two sides here that are negotiating from a 
differing opening stance. ICANN's answer isn't merely about timing.

Many in the Internet communities have asked for separability, and the 
IETF's Supplemental Agreement to the MoU with ICANN have been used by 
some people therein to have ICANN make commitments to that effect, 
furthering the separability end game. When they (we) say that it was 
always separable, that may or may not be the case but those statements 
are also furthering separability in the negotiation, something that is 
desirable.

Icann *itself* does decide if it acquiesces or not to the SLA, it does 
not ask NTIA. When it invokes a purported NTIA or US gov position, it is 
self-serving. In this case it is both invoking a pseudo-legal 
justification to obtain clearly worded separability commitments from it 
and it is also trying to resonate with some parts of the US gov by 
mapping separability on to some other points ― losing the american 
foothold ― that may garner ICANN some support for its 
monopoly_in_perpetuity_is_our_preference stance. That stance, btw, isn't 
morally abject and it is completely understandable. We just have another 
somewhat opposite stance.

This story isn't about ICANN trying to bypass the process. It's about 
them knowing that the process is larger than the actual process. And ... 
we know that too.

So  ... nothing *legal* about their *legal* justification. Except the dress.

Nicolas

On 2015-04-30 1:23 PM, Seun Ojedeji wrote:
>
> Hi Prof,
>
> I read the mail before responding as well(as you know I am also on 
> that list) and you are right that there is a concern which I also 
> agree with. However, it's our interpretation of the concern that I 
> think we disagree on.
>
> Below is the exact wording of the IAB chair:
>
> " ICANN has informed
> us that they are unable to agree to that text right now.  ICANN told
> us that, in their opinion, agreeing to that text now would possibly
> put them in breach of their existing agreement with the NTIA. "
>
> The use of the phrase "right now" is what I think makes the difference 
> in our interpretation of the situation.
>
> At ICANN 49, a question was raised during public forum whether the 
> NTIA contract was weightier than the existing MoU; i.e if NTIA decide 
> to assign IANA to another operator, can the respective 
> communities(based on their current mou) insist that ICANN has meet up 
> with their SLA and by so should continue to operate their function?
>
> There was no definite response to that question and I think that is 
> what is happening in this current situation; if ICANN signs such SLA, 
> that would indirectly imply double oversight body. The  specific 
> section below is what buttresses my point:
>
> " It is possible in the future that the operation of the protocol
>      parameters registries may be transitioned from ICANN to subsequent
>      operator(s).  It is the preference of the IETF community that, as
>      part of the NTIA transition, ICANN acknowledge that it will carry
>      out the obligations established under C.7.3 and I.61 of the
>      current IANA functions contract between ICANN and the NTIA
>      [NTIA-Contract] to achieve a smooth transition to subsequent
>      operator(s), should the need arise. "
>
> So how can ICANN sign an agreement reflecting the statement above 
> without actually either getting permission from NTIA OR having the 
> current agreement with NTIA terminated. The requirements listed by IAB 
> chair were developed in response to ICG request and that process is 
> on-going, so I don't see why implementation should begin before NTIA's 
> approval.
>
> Overall, I think the important question has been asked on the 
> IANA-plan list which is to know the actual text in the new SLA that 
> ICANN can not agree to "at the moment". Until such information is made 
> available, ordinary community member like me (and you?) would only be 
> speculating. So my interpretation of the issue may be largely 
> incorrect but it's based on the information currently available to me.
>
> Regards
>
> sent from Google nexus 4
> kindly excuse brevity and typos.
>
> On 30 Apr 2015 17:36, "Milton L Mueller" <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>     Seun:
>
>     I suggest that you read the letter from the IETF people.
>
>     “It is our view that the substance of the statements above is already
>
>     part of our agreement with ICANN, and that we are merely elaborating
>
>     details of that existing agreement.
>
>     I could be wrong, but I don’t think IETF would be publicizing this
>     the way it is if it were not concerned.
>
>     Given the precedent established with CRISP, ICANN’s refusal to
>     accept an agreement that, in IETF’s opinion, already existed, is
>     troublesome to say the least.
>
>     --MM
>
>     *From:*NCSG-Discuss [mailto:[log in to unmask]
>     <mailto:[log in to unmask]>] *On Behalf Of *Seun Ojedeji
>     *Sent:* Thursday, April 30, 2015 11:55 AM
>     *To:* [log in to unmask]
>     <mailto:[log in to unmask]>
>     *Subject:* Re: [NCSG-Discuss] Ominous update on the IANA transition
>
>     Hi Milton,
>
>     Thanks for this share, I am not sure what was posted on the
>     IANA-plan list by the IAB chair implied that ICANN is refusing
>     IETF from moving it's function if required.
>     I understood his message to imply ICANN is refusing to sign and 
>     agreement of such ability because they already have a commitment
>     on such with the NTIA.
>     I am not a lawyer, but I think it makes a lot of sense to activate
>     such agreement at the termination of the other.
>
>     A question to ask is whether ICANN is committed to signing the SLA
>     once NTIA relinquishes it's current agreement.
>
>     Regards
>
>     sent from Google nexus 4
>     kindly excuse brevity and typos.
>
>     On 30 Apr 2015 14:27, "Milton L Mueller" <[log in to unmask]
>     <mailto:[log in to unmask]>> wrote:
>
>         Dear NCSG:
>
>         It’s now official: ICANN doesn’t even want to let the IETF
>         have a choice of its IANA functions operator.
>
>         Those of you who read my blog post on ICANN’s interactions
>         with the numbers community
>         <http://www.internetgovernance.org/2015/04/28/icann-wants-an-iana-functions-monopoly-and-its-willing-to-wreck-the-transition-process-to-get-it/>
>         will already know that ICANN is refusing to accept the
>         consensus of the numbers community by recognizing its
>         contractual right to terminate its IANA functions operator
>         agreement with ICANN. In that blog, I referred to second-hand
>         reports that IETF was encountering similar problems with
>         ICANN. Those reports are now public; the chairs of the IETF,
>         IAB and IETF Administrative Oversight Committee have sent a
>         letter to their community
>         <http://www.ietf.org/mail-archive/web/ianaplan/current/msg01680.html>
>         noting that ICANN is refusing to renew their supplemental
>         service level agreement because it includes new provisions
>         designed to facilitate change in IANA functions operators
>         should IETF become dissatisfied with ICANN.
>
>         These are truly shocking moves, because in effect ICANN’s
>         legal staff is telling both the numbers and the protocols
>         communities that they will not accept the proposals for the
>         IANA transition that they have developed as part of the IANA
>         Stewardship Coordination Group (ICG) process. In both cases,
>         the proposals were consensus proposals within the affected
>         communities, and were approved by the ICG as complete and
>         conformant to the NTIA criteria. Thus, ICANN is in effect
>         usurping the entire process, setting itself (rather than ICG
>         and NTIA) as the arbiter of what is an acceptable transition
>         proposal.
>
>         The key point of conflict here seems to be the issue of
>         whether ICANN will have a permanent monopoly on the provision
>         of IANA functions, or whether each of the affected communities
>         – names, numbers and protocols – will have the right to choose
>         the operator of their global registries. Separability is
>         explicitly recognized by the Cross community working group on
>         Names as a principle to guide the transition, and was also
>         listed as a requirement by the CRISP team. And the IETF has
>         had an agreement with ICANN giving them separability since
>         2000 (RFC 2860 <https://tools.ietf.org/html/rfc2860>).  Yet
>         despite the wishes of the community, ICANN seems to insist on
>         a monopoly and seems to be exploiting the transition process
>         to get one.
>
>         Of course, a severable contract for the IANA functions is the
>         most effective and important form of accountability. If the
>         users of IANA are locked in to a single provider, it is more
>         difficult to keep the IANA responsive, efficient and
>         accountable. Given the implications of these actions for the
>         accountability CCWG, I hope someone on that list will forward
>         this message to their list, if someone has not noted this
>         event already.
>
>         Milton L Mueller
>
>         Laura J. and L. Douglas Meredith Professor
>
>         Syracuse University School of Information Studies
>
>         http://faculty.ischool.syr.edu/mueller/
>
>         Internet Governance Project
>
>         http://internetgovernance.org <http://internetgovernance.org/>
>