Re: [Ianaplan] Update on IANA Transition & Negotiations with ICANN

John C Klensin <> Fri, 01 May 2015 15:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2D4C81A01CB for <>; Fri, 1 May 2015 08:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5kukHXWz2jEs for <>; Fri, 1 May 2015 08:41:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E4CD1A1B56 for <>; Fri, 1 May 2015 08:41:15 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1YoD3v-000OWx-ES; Fri, 01 May 2015 11:41:11 -0400
Date: Fri, 01 May 2015 11:41:06 -0400
From: John C Klensin <>
To: Seun Ojedeji <>, Andrew Sullivan <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Ianaplan] Update on IANA Transition & Negotiations with ICANN
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 May 2015 15:41:17 -0000

Hmm.  I was a little concerned that your exchange with Andrew
might deepen the confusion.  Let me try a different perspective
with the understanding that I'm speaking for myself only and
doing a certain amount of guessing -- I'm not enough part of
"the leadership" to speak for them even if I wanted to.

--On Friday, May 01, 2015 14:31 +0100 Seun Ojedeji
<>; wrote:

>> On Thu, Apr 30, 2015 at 07:25:10PM +0100, Seun Ojedeji wrote:
>> > 
>> > Do I understand this to mean that IETF  wants to get it's
>> > RFP response to ICG activated and operational before
>> > conclusion of the transition
>> process?
>> I don't think so.
> Great. This is the response i expected and i would have been
> surprised if otherwise. Based on above then it may be
> important to clarify the section of the IAB chair's(your)
> statement below:
> So generally speaking (and based on information available to
> me), it seem this is a timing issue and there may just be need
> to clarify from ICANN if they are fine with agreeing with the
> term post-NTIA.
> As you have rightly stated, I believe the current agreement
> should-be/is sufficient enough at ensuring IETF continue to
> get its usual IANA function service.

There is, indeed, a timing issue with this and, IMO, most of it
has very little to do with IANAPlan or the transition process.
It helps me to think about what is going on as two separate
activities and threads.  One is the regular, annual, process of
the IAOC and IAB working with ICANN to update the IANA SLA,
setting new targets and clarifying whatever needs to be
clarified.  In part because that is mostly a contractual matter,
the IETF community has rarely been actively aware of those
discussions beyond the usual plenary reports (no particular
secrets, just the IAOC and IAB doing their jobs so there is some
hope of the rest of us being able to get technical/standards
work done).  The other is the specific set of issues associated
with NTIA-IANA transition planning and this WG.

Now, ever since the annual SLA approach was adopted (and really
going back to the March 2000 approval of the MOU included in RFC
2860), the IETF (and, as far as we know, ICANN) have been
working based on the content of that document and some shared
assumptions and interpretations of it.  For this year's version,
the IETF sought to clarify those relationships and
interpretations by incorporating some text into the SLA.  From
the point of view of those SLA discussions, at least as I
understand it, nothing has changed: we are just repeating
existing agreements into the SLA.  The fact that the decision to
clarify those points in the SLA to be sure of them arose from
IANAPlan discussions is, from the SLA point of view, a
coincidence: we could reasonably have included the same
provisions in the SLA at any time (and, from my personal point
of view, should have done so years ago).

Still from the SLA point of view, ICANN appears to have said "we
cannot formally agree, in the SLA, to provisions you have
believed were in effect for years".   That does not make me very
happy and, IMO, should not make anyone who has been depending on
the MOU very happy.   Whether it is serious or not, and whether
it changes the way we look at and interpret even the current
SLA, is ultimately a contractual matter that I'm happy to leave
to the IAB, IAOC, and the IAOC's legal advisors.  I would
encourage others to leave it to them too -- attacks of
speculation and amateur lawyering are rarely productive and tend
to suppress more useful discussions.  

Now, if the IAOC were to conclude either that it was urgent to
update the existing provisions and targets of the SLA or that
questions about our assumptions require an SLA update, now, that
would presumably be an issue with a schedule independent of any
transition-related calendar.  

The transition and IANAPlan-related issues are a different
matter with, as your comments suggest, a different schedule.
As you also suggest, there is at least a potential for ICANN to
agree to do something during the transition or post-transition
that they don't feel able to do now.