Re: [Ianaplan] last call and IESG processing summary for draft-ietf-ianaplan-icg-response
John C Klensin <john-ietf@jck.com> Fri, 19 December 2014 14:54 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 77E241A700D for <ianaplan@ietfa.amsl.com>; Fri, 19 Dec 2014 06:54:08 -0800 (PST)
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 7B8lYsUTNjpi for <ianaplan@ietfa.amsl.com>; Fri, 19 Dec 2014 06:54:07 -0800 (PST)
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 14AD41A00D8 for <ianaplan@ietf.org>; Fri, 19 Dec 2014 06:54:06 -0800 (PST)
Received: from h8.int.jck.com ([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 1Y1ywK-0008RI-AZ; Fri, 19 Dec 2014 09:54:00 -0500
Date: Fri, 19 Dec 2014 09:53:55 -0500
From: John C Klensin <john-ietf@jck.com>
To: JFC Morfin <jefsey@jefsey.com>
Message-ID: <95C4C6D9E29456672DEE6A92@JcK-HP8200.jck.com>
In-Reply-To: <20141219110431.5AE911A9089@ietfa.amsl.com>
References: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net> <20141219110431.5AE911A9089@ietfa.amsl.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/lpXJZI2tFqMKMgsOm_zZ7RR7krs
Cc: "Ianaplan@Ietf. Org" <ianaplan@ietf.org>, Jari Arkko <jari.arkko@piuha.net>, draft-ietf-ianaplan-icg-response.all@tools.ietf.org
Subject: Re: [Ianaplan] last call and IESG processing summary for draft-ietf-ianaplan-icg-response
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, 19 Dec 2014 14:54:08 -0000
Jefsey, Perhaps because we have corresponded more over the years, unlike Jari, I understood your comments and the note excerpted below confirmed my understanding. Part of that understanding is that the vast majority of your text and comments below are about your vision for computer-enabled networking going forward and where you think the IETF and other bodies fit in that model. While the I-D does contain some description of parts of how the IETF works and, in particular, how it relates to the IANA function, it doesn't make normative changes to IETF (or IAB, ISOC, etc.) relationships to the present or future Internet beyond the very narrow issues of IANA relationships and oversight. No matter what you might read into what is said, for it to do so would be out of scope for the WG and would represent changes to which some of us would object strenuously, especially if those changes were hidden in discussions of NTIA-IANA relationships and the conditions and implications of changes in them. Details below. --On Friday, December 19, 2014 12:04 +0100 JFC Morfin <jefsey@jefsey.com> wrote: >... > It is difficult to understand this sentence since the "this" > is not explained as being that from now on, the IETF will > still be working for the future internet ,in its own way and > for its own mission but will not be exclusive or responsible > for it any more. The document changes nothing in that area, including any notions of exclusivity and/or responsibility. I don't know whether we would agree about how "exclusive or responsible" things are intended or desired to be today (or how they are practiced), but I am quite certain that this document changes nothing in those areas. > This responsibility is here understood as per RFC 3935: "when > the IETF takes ownership of a protocol or function, it accepts > the responsibility for all aspects of the protocol, even > though some aspects may rarely or never be seen on the > Internet. Conversely, when the IETF is not responsible for a > protocol or function, it does not attempt to exert control > over it, even though it may at times touch or affect the > Internet." That statement has little or nothing to do with the IANA function, the IETF-IANA relationship, or IANA oversight. The present draft does not change anything about it, even to reaffirm it. > The IAB still has to commit in this document. However, > eventually ISOC will be the one having to decide, since the > I_D means that ISOC would not own the internet anymore (in the > RFC 3935 meaning hereinabove). I do not believe that any of IETF, the IAB, or ISOC have claimed at any time to "own the Internet". Even if they had, there is nothing in this document that would change or ratify that status. Because the document changes nothing in those areas, your subsequent assertions about 'the end of the "status quo" strategy' and 'affirmation' are just simply not relevant. >... > Now, as a non-IETF > technically competing WG, I need to have the practicalities of > this new situation explained and how IETF stakeholders intend > to adapt to the MYCANN/CORPCANN/GOVCANN middlewares and the > multitechnology environment that we will face and build > together. > > We need to know if the IAB/IETF, or someone else they would > accept, intends to launch a normative multistakeholder >... Whether you "need" those things or not, and whether you can demand that the IETF or IAB respond to those needs, they simply have nothing to do with the substantive subject matter of this document or the scope of the WG. best regards, john
- [Ianaplan] last call and IESG processing summary … Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Richard Hill
- Re: [Ianaplan] last call and IESG processing summ… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… John C Klensin
- Re: [Ianaplan] last call and IESG processing summ… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Richard Hill
- Re: [Ianaplan] last call and IESG processing summ… Andrew Sullivan
- Re: [Ianaplan] last call and IESG processing summ… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… Abdussalam Baryun
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- [Ianaplan] ***SPAM*** 21.631 (5) Re: last call an… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… Milton L Mueller
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Milton L Mueller
- Re: [Ianaplan] last call and IESG processing summ… Brian E Carpenter
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Seun Ojedeji
- Re: [Ianaplan] last call and IESG processing summ… Milton L Mueller
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko