Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
Geoff Huston <gih@apnic.net> Thu, 22 November 2012 05:51 UTC
Return-Path: <gih@apnic.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2343821F850E; Wed, 21 Nov 2012 21:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.559
X-Spam-Level:
X-Spam-Status: No, score=-98.559 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX53a6AgDUfK; Wed, 21 Nov 2012 21:51:03 -0800 (PST)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7D21F850D; Wed, 21 Nov 2012 21:51:01 -0800 (PST)
Received: from [192.168.51.200] (unknown [87.213.29.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 441B9B68B7; Thu, 22 Nov 2012 15:50:56 +1000 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <19339.1353524987@epsilon.noi.kre.to>
Date: Thu, 22 Nov 2012 16:50:40 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <08FCD406-F556-4F7E-BA98-9591D161A3A6@apnic.net>
References: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <CAKFn1SF4+k5gWip-WBNfbjt-qAafPbTSY8L_EBLA9Pqvbw4=kQ@mail.gmail.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> <19339.1353524987@epsilon.noi.kre.to>
To: Robert Elz <kre@munnari.OZ.AU>
X-Mailer: Apple Mail (2.1499)
Cc: "iesg@ietf.org IESG" <iesg@ietf.org>, "ietf@ietf.org List" <ietf@ietf.org>, lisp@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Nov 2012 05:51:04 -0000
With respect Robert, I disagree with your line of argument and I disagree with your assertion that a reference to an existing RFC is "bogus under these circumstances" This eid draft does not claim to obsolete or update either the description of roles and responsibilities in RFC2860 or the directions to the IANA in RFC4773, yet the document's directions to the IANA appear to me to be inconsistent with those existing procedures and policies. To claim, if I understand your line of argument correctly, that every RFC essentially is an implicit update of all existing RFCs, and every RFC does not need to explicitly obsolete or update any other RFC, as it does does so by default upon publication of the RFC is not a line of argument that I find that I could agree with. For me, it's like proclaiming that: "everything I do is right, and if whatever I do contravenes existing processes and procedures then my actions implicitly update those processes and procedures such that everything I do is right" I find that I cannot agree with such a circular self-referential line of reasoning. Instead, I believe that the processes and processes that the IETF follow are deliberative decisions, and that we update and amend those processes and procedures explicitly, and documents that perform such updates say so explicitly, and are accepted and published on the basis of explicit consideration of the processes and procedures and acceptance of the amendment. But I appreciate that I am by training a mathematician and not a lawyer, and you may indeed be making some critical observations about the nature of the IETF's processes and procedures whose finer points may well have escaped me. However, it seems to me that it would be more productive for the IETF to consider that this issue is a distinct issue, and not confound the consideration of the IETF Last Call of this particular eid draft with the broader issue of the manner by which the IETF crafts and maintains its own procedures, processes and policies. regards, Geoff speaking for myself and noone else On 22/11/2012, at 6:09 AM, Robert Elz <kre@munnari.OZ.AU> wrote: > Date: Wed, 21 Nov 2012 17:16:58 +1100 > From: Geoff Huston <gih@apnic.net> > Message-ID: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> > > I have no idea whether the allocation requested is reasonable or not, > I haven't read the draft (and unless it becomes more widely used than > currently, might never do so), but I do know that this argument ... > > | The guidelines for IP address allocations were documented in RFC2050, > | adopted in November 1996 as a Best Current Practice. ... > > is totally bogus in these circumstances. > > The rules in RFCs and BCPs bind ordinary users making ordinary requests > for address space - were I to approach IANA with a request for address > space to be allocated, a quick denial quoting the relevant RFC would indeed > be the correct response. > > But when the IETF publishes an updated RFC, that always overrides any > earlier RFC, and establishes new policy - either for the general case, or > perhaps (as seems to be happening here) just a one off override of the > normal rules. > > Doing that is always acceptable, whatever the issue - it is never adequate > to simply refuse to consider such requests upon the basis that they don't > follow the rules and should be done some other way. > > Now, when the IETF (via the last call consensus mechanism) consider whether > the proposed RFC should be published, it is perfectly reasonable to point > out the existing policy, and ask for reasons why use of that mechanism would > not be adequate - if the proponents cannnot explain why doing it the way > they are suggesting is required, or at least is better than the normal way, > then the request (to publish the RFC, not just to perform whatever allocation > it requested - that just falls out of the failure to publish the RFC) should > be refused. > > On the other hand, if the proponents can convince the IETF that the > procedure they're suggesting is the best way to proceed, then that's > what should happen - and that it isn't being done the way that the > normal allocation rules would suggest it should be done is 100% irrelevant. > > If you have an argument against the proposal, please make it upon the > merits of the request, and not based upon some supposed viloation of > address allocation quidelines. > > What the result will be I have no idea - I don't know if this allocation > should happen or not. I might suggest however, that if Noel is correct > about the way this allocation would be used (and Noel usually is correct) > then it may be that an assignment out of the 0::/3 address space (which is > out of the ordinary allocation space for which the guidelines apply) > sounds like it might be the right thing to do - perhaps something like > 10f0::/12 (or something near there not currently allocated). > > kre
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Roger Jørgensen
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… SM
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George Michaelson
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… Bert Wijnen (IETF)
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Luigi Iannone
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… Luigi Iannone
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Luigi Iannone
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Luigi Iannone
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… Luigi Iannone
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… Bert Wijnen (IETF)
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Paul Vinciguerra
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… SM
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Geoff Huston
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Arturo Servin
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Arturo Servin
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George Michaelson
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Joel M. Halpern
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Arturo Servin
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George Michaelson
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George Michaelson
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Brian E Carpenter
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Arturo Servin
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Roger Jørgensen
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George, Wes
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Joel M. Halpern
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Brian E Carpenter
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Paul Vinciguerra
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Paul Vinciguerra
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Joel M. Halpern
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… SM
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Cameron Byrne
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Cameron Byrne
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Geoff Huston
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Joel Halpern Direct
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… heinerhummel
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Geoff Huston
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… SM
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George, Wes
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Robert Elz
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George, Wes
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Geoff Huston
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Roger Jørgensen
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Brian E Carpenter
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Robert Elz
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Brian Haberman
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Luigi Iannone