Re: [Ianaplan] Time frame inquiry

Jari Arkko <> Wed, 27 May 2015 23:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 90C971A8ADD for <>; Wed, 27 May 2015 16:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m-7pU44GVblM for <>; Wed, 27 May 2015 16:00:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D3F891A1AD9 for <>; Wed, 27 May 2015 16:00:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65C452CED5; Thu, 28 May 2015 02:00:15 +0300 (EEST) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0-g_d-NS9qI3; Thu, 28 May 2015 02:00:14 +0300 (EEST)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id 88EAD2CED3; Thu, 28 May 2015 02:00:14 +0300 (EEST) (envelope-from
Content-Type: multipart/signed; boundary="Apple-Mail=_79C4CBC8-D784-4807-896F-8080B62336B4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <>
In-Reply-To: <>
Date: Thu, 28 May 2015 02:00:11 +0300
Message-Id: <>
References: <> <> <> <>
To: Russ Housley <>, John Curran <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "Ianaplan@Ietf. Org" <>
Subject: Re: [Ianaplan] Time frame inquiry
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: Wed, 27 May 2015 23:00:19 -0000

I think we are going about this from a slightly wrong direction.
I think there’s some desire on ICANN side to transition in an
atomic fashion. Right or wrong...

But I think the answer from our side is essentially: we are
ready to proceed with the (final) steps of the transition today,
if NTIA, ICANN, etc. are. And these steps are “final” because
much of the necessary structure in our case has been built
in earlier years. And at least from my perspective those
steps could also be seen as our normal course of yearly
business improvement, rather than some grandiose
moment that various people need to get very excited
about :-)

Anyway, also, as discussed in the last days, different directions
in the details for the CWG process might have effects that we have
to consider.

And of course, if at any point in time someone wants us to
do something different or more, that would have an effect.

But I think my answer today would be as follows. Basing it
on John’s excellent text:

“The IETF is ready today to take the next steps in the
implementation of the transition of the stewardship.
In our case, most of the necessary framework is already
in place and implemented in preceding years.

From our perspective the remaining step is an updated
SLA with ICANN which addresses two issues. The update
has been drafted and from our perspective could be
immediately executed. When executed — and with
the NTIA contract with ICANN is voided -- from our
perspective the protocol parameter community
has completed the stewardship transition.

Of course, we are not alone in this process. Interactions
with other parts of the process may bring additional
tasks that need to be executed either before or
after the transition. First, the ICG, the RIRs,
and IETF have discussed the possibility of aligning
the treatment of IANA trademarks. The IETF Trust
has signalled that it would be willing to do this, if
asked. We are awaiting to coordination on this
to complete, but see no problem in speedy
execution once the decision is made. From our
perspective this is not a prerequisite for the transition,

Second, the names community has developed a
“Post Transition IANA” (PTI) structure in their
proposal. Not all details of that are clear at this
point in time. Depending on the final setting of
those details, this may require no further action
from the IETF, if we can keep our existing contracts
in place. That is our preference. However, if the names
community decides on a structure that requires changes
to our contracts or further participation in the internal
structure governing the PTI, this will require further
work and community agreement.”