Re: [Ianaplan] Time frame inquiry

Jari Arkko <> Thu, 04 June 2015 12:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AC7031ACEEC for <>; Thu, 4 Jun 2015 05:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XANoNKiZ2fWa for <>; Thu, 4 Jun 2015 05:04:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3E91C1AD0B2 for <>; Thu, 4 Jun 2015 05:03:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96A292CED9; Thu, 4 Jun 2015 15:03:39 +0300 (EEST) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yGGNzqIKrqPP; Thu, 4 Jun 2015 15:03:37 +0300 (EEST)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id C22AA2CED5; Thu, 4 Jun 2015 15:03:37 +0300 (EEST) (envelope-from
Content-Type: multipart/signed; boundary="Apple-Mail=_441F88A9-0B56-4DC3-BDB1-596789D394D3"; 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, 4 Jun 2015 15:03:36 +0300
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "Ianaplan@Ietf. Org" <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "Leslie Daigle \(ThinkingCat\)" <>
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: Thu, 04 Jun 2015 12:04:16 -0000

I wouldn’t worry too much about the signatories that is perhaps more of a practical
matter than anything else. In general, reducing the reliance on persons in official
roles and highlighting the role of the community is important in this and many
other topics.

But being clear about the status of any opinion is important, and we
didn’t make that yet clear in the previous text.

I plan to send this note to the ICG later today unless someone screams
otherwise. I also plan to send a copy to the CWG list for information,
given our reference relating to the PTI arrangements.


This is a response to a query regarding transition finalisation and
implementation time frames, sent to the IANAPLAN working
group list by the chairs of the IANA Transition Coordination
Group (ICG) on May 27th.

While I am carrying this response back to the ICG, the substance
of this response has been discussed in the IANAPLAN working
group and the relevant parts of IETF leadership. I believe this
response represents the (rough) consensus opinion that
emerged in the discussion, as well as the current state
of IANA arrangement updates that our leadership bodies
have been working on.

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.

The remaining step is an updated agreement with
ICANN which addresses two issues. These issues are
outlined in Section 2.III in the Internet Draft

  o  The protocol parameters registries are in the public domain.  It
     is the preference of the IETF community that all relevant parties
     acknowledge that fact as part of the transition.

  o  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.  Furthermore, in the event of
     a transition it is the expectation of the IETF community that
     ICANN, the IETF, and subsequent operator(s) will work together to
     minimize disruption in the use of the protocol parameters registries
     or other resources currently located at

The IETF Administrative Oversight Committee (IAOC) has
decided to use an update of our yearly IETF-ICANN Service Level
Agreement (SLA) as the mechanism for this updated
agreement. They have drafted the update and from our
perspective it could be immediately executed. Once the updated
agreement is in place, the transition would be substantially
complete, with only the NTIA contract lapse or termination
as a final step. 

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 and domains. The
IETF Trust has signalled that it would be willing to do this,
if asked. We are awaiting 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,

In addition, the names community has proposed the
creation of a 'Post Transition IANA' (PTI).  If the existing
agreements between the IETF and ICANN remain in place
and the SLAs discussed above are not affected, the IETF​ 
transition would take place as described above.  That is
our preference.  If the final details of the PTI plan require
further action from the IETF, more work and community
agreement would be required.  The timeline for that work
cannot be set until the scope is known.

Jari Arkko, IETF Chair
(reporting his summary of the situation)