Re: [Ianaplan] Update on IANA Transition & Negotiations with ICANN
John C Klensin <john-ietf@jck.com> Fri, 01 May 2015 15:41 UTC
Return-Path: <john-ietf@jck.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 2D4C81A01CB for <ianaplan@ietfa.amsl.com>; Fri, 1 May 2015 08:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kukHXWz2jEs for <ianaplan@ietfa.amsl.com>; Fri, 1 May 2015 08:41:15 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4CD1A1B56 for <ianaplan@ietf.org>; Fri, 1 May 2015 08:41:15 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) 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 <john-ietf@jck.com>
To: Seun Ojedeji <seun.ojedeji@gmail.com>, Andrew Sullivan <ajs@anvilwalrusden.com>
Message-ID: <94839648711C2BC9EBE94724@JcK-HP8200.jck.com>
In-Reply-To: <CAD_dc6hwLXw3TOGGksO=tWsZ87gCX-EKXtybOL6e5o3OfrQNkQ@mail.gmail.com>
References: <20150430115751.GE65715@mx2.yitter.info> <CAD_dc6iu74FVHGq+17zzT2Yb-deQ1WeP8UNZcakUs7Hq1LXUtg@mail.gmail.com> <20150501130948.GF68855@mx2.yitter.info> <CAD_dc6hwLXw3TOGGksO=tWsZ87gCX-EKXtybOL6e5o3OfrQNkQ@mail.gmail.com>
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-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/fSWjy0WymlttKLWVukxPfxsaajw>
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] Update on IANA Transition & Negotiations with ICANN
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, 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 <seun.ojedeji@gmail.com> 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. john
- [Ianaplan] Update on IANA Transition & Negotiatio… Andrew Sullivan
- Re: [Ianaplan] Update on IANA Transition & Negoti… 'Andrew Sullivan'
- Re: [Ianaplan] Update on IANA Transition & Negoti… Richard Hill
- Re: [Ianaplan] Update on IANA Transition & Negoti… 'Andrew Sullivan'
- Re: [Ianaplan] Update on IANA Transition & Negoti… Richard Hill
- Re: [Ianaplan] Update on IANA Transition & Negoti… Seun Ojedeji
- Re: [Ianaplan] Update on IANA Transition & Negoti… Andrew Sullivan
- Re: [Ianaplan] Update on IANA Transition & Negoti… Seun Ojedeji
- Re: [Ianaplan] Update on IANA Transition & Negoti… John C Klensin
- Re: [Ianaplan] Update on IANA Transition & Negoti… Milton L Mueller
- Re: [Ianaplan] Update on IANA Transition & Negoti… Bernard Aboba
- Re: [Ianaplan] Update on IANA Transition & Negoti… JFC Morfin
- Re: [Ianaplan] Update on IANA Transition & Negoti… Brian E Carpenter
- Re: [Ianaplan] Update on IANA Transition & Negoti… Jefsey