Re: [Ianaplan] Time frame inquiry

Jari Arkko <jari.arkko@piuha.net> Thu, 28 May 2015 05:16 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24101A8A9C for <ianaplan@ietfa.amsl.com>; Wed, 27 May 2015 22:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8kxmCWJbfvj for <ianaplan@ietfa.amsl.com>; Wed, 27 May 2015 22:16:01 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A19851A8A47 for <ianaplan@ietf.org>; Wed, 27 May 2015 22:16:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5B2F62CC49; Thu, 28 May 2015 08:15:58 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2MTU6FhEhOg; Thu, 28 May 2015 08:15:57 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 7A8562CC5D; Thu, 28 May 2015 08:15:57 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_54B17E45-198D-49E9-B16D-ED870D4618C3"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <55669A78.3020309@cisco.com>
Date: Thu, 28 May 2015 08:15:55 +0300
Message-Id: <C8B9D0E8-C363-4618-8941-D0027B86EB7A@piuha.net>
References: <D15A3C14-F268-4CF1-B942-BAE57B281C58@cooperw.in> <556D3AAA-1655-4785-9395-8F6CD0B73E44@vigilsec.com> <5F8F0771-C77B-4D90-811B-501A4EC79268@istaff.org> <893FE3E3-A2DD-40D8-B39F-1EB24DFE1806@vigilsec.com> <97267ED7-D8A2-4A64-AB74-07434190DD89@piuha.net> <CA+9kkMBZq_U+CC5Jzv5T3pL7qasUHSfv-Gu8q4P36+phABXxzg@mail.gmail.com> <4AB120DC-AFB1-4915-B6C5-7417FB989878@piuha.net> <55669A78.3020309@cisco.com>
To: Eliot Lear <lear@cisco.com>, Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/QqLIkA5EK4Swz_7SQV_ri7Hy9fs>
Cc: "Ianaplan@Ietf. Org" <ianaplan@ietf.org>
Subject: Re: [Ianaplan] Time frame inquiry
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 05:16:03 -0000

Eliot:

> I like the text below modulo one issue: the IANAPLAN proposal did not specify how the IAOC would implement the requested changes (whether through the SLA or another side agreement).  I would prefer that we stuck to that approach and not name which agreement the changes go into (SLA or a one-time supplemental agreement).

Ok.

Trying to take this and Ted’s comments into account:

“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
draft-ietf-ianaplan-icg-response-09.txt:

   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 the protocol parameters registries
      or other resources currently located at iana.org.

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. 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,
however.

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​ 
ransition 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