Re: [Ianaplan] Time frame inquiry

Russ Housley <housley@vigilsec.com> Fri, 29 May 2015 15:49 UTC

Return-Path: <housley@vigilsec.com>
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 472FC1ACD5C for <ianaplan@ietfa.amsl.com>; Fri, 29 May 2015 08:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.899
X-Spam-Level:
X-Spam-Status: No, score=-103.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 JD6cAiexYNrP for <ianaplan@ietfa.amsl.com>; Fri, 29 May 2015 08:49:55 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id ADBBD1ACD5A for <ianaplan@ietf.org>; Fri, 29 May 2015 08:49:54 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 29E5B9A4070 for <ianaplan@ietf.org>; Fri, 29 May 2015 11:49:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Q0UHBt+ZTCN9 for <ianaplan@ietf.org>; Fri, 29 May 2015 11:48:29 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C431D9A4057 for <ianaplan@ietf.org>; Fri, 29 May 2015 11:49:22 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary="Apple-Mail-166--659181176"
Date: Fri, 29 May 2015 11:49:11 -0400
In-Reply-To: <C8B9D0E8-C363-4618-8941-D0027B86EB7A@piuha.net>
To: ianaplan@ietf.org
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> <C8B9D0E8-C363-4618-8941-D0027B86EB7A@piuha.net>
Message-Id: <6BCB4C30-034A-4D13-AD89-88B0719DB75C@vigilsec.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/WbClFlqCaM9zOnBntiOnx3MTGN4>
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: Fri, 29 May 2015 15:49:57 -0000

Thanks for pulling all of the pieces together.  I t looks good to me.

I think it should be signed by the IANAPLAN WG Chairs.  They were the ones that received the letter.

Russ

P.S.  Should we put the letter and the response in the liaison system to make them easy to find?


On Wed, May 27, 2015 at 10:15 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
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