Re: [Idr] WG Last Call on Proposed IANA procedures for BGP Well-known communities
Brian Dickson <briand@ca.afilias.info> Wed, 13 August 2008 06:00 UTC
Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 025A03A697C;
Tue, 12 Aug 2008 23:00:10 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B64833A6959
for <idr@core3.amsl.com>; Tue, 12 Aug 2008 23:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level:
X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.701,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id a79xoPMXSRlx for <idr@core3.amsl.com>;
Tue, 12 Aug 2008 23:00:07 -0700 (PDT)
Received: from vgateway.libertyrms.info (vgateway.libertyrms.info
[207.219.45.62])
by core3.amsl.com (Postfix) with ESMTP id 6F5923A6938
for <idr@ietf.org>; Tue, 12 Aug 2008 23:00:07 -0700 (PDT)
Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87])
by vgateway.libertyrms.info with esmtp (Exim 4.22)
id 1KT9Oy-0006Sz-CH; Wed, 13 Aug 2008 02:00:08 -0400
Message-ID: <48A27868.3000208@ca.afilias.info>
Date: Wed, 13 Aug 2008 02:00:08 -0400
From: Brian Dickson <briand@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: David Ward <dward@cisco.com>
References: <200808121939.m7CJdJu33721@magenta.juniper.net>
<48A1EF25.3080606@ca.afilias.info>
<200808130022.m7D0MSu28182@magenta.juniper.net>
<0BD387FF-1A20-4E0D-A3B8-08C21CFF80CB@cisco.com>
In-Reply-To: <0BD387FF-1A20-4E0D-A3B8-08C21CFF80CB@cisco.com>
X-SA-Exim-Mail-From: briand@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Cc: Yakov Rekhter <yakov@juniper.net>, idr@ietf.org
Subject: Re: [Idr] WG Last Call on Proposed IANA procedures for BGP
Well-known communities
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org
David Ward wrote: > Thanks Yakov, I think what you have below is exactly what is in my > original proposal with clarifying headers. I apologize for ambiguous > language in the description of what I was trying to accomplish. I > simply cut and pasted from RFC 4360 (BGP Extended Communities) hoping > that similarity of language would actually be easier :-) The text > under question technically has no bearing and will not even appear in > the registry. All that appears in the registry is the range and > allocation procedure as per the proposal and clarified below. > > Please take a look at the ext-comm registry for an example: > > http://www.iana.org/assignments/bgp-extended-communities > > You will not see the text cribbed from 4360 and you won't see it in > the new procedures for well-known comms. > > HIH > While it isn't the case, by any means, that everyone needs to be completely satisfied by proposals, it's nice when it happens. :-) I'm thrilled with this change, and whole-heartedly endorse the modified proposal. I have reviewed the proposal and am in favor of it moving to whatever the next step is. Brian > -DWard > > On Aug 12, 2008, at 7:22 PM, Yakov Rekhter wrote: > >> Brian, >> >>>>> Basically, what is missing, in addition to some formalization of >>>>> the process, is the ability to use RFC 4020 Early IANA Assignments, >>>>> from which early work can progress from draft, to initial >>>>> implementation, >>>>> to multi-vendor implementation, to working group consensus. The >>>>> whole "consensus and running code" thing, which I absolutely agree >>>>> with, particularly in the IDR area (where, more than anywhere else, >>>>> interoperability is "it"). >>>>> >>>> >>>> Here is a quote from Dave's proposal: >>>> >>>> I am proposing a 50/50 split of the upper range of currently >>>> reserved space between the "First Come First Served" policy >>>> defined in RFC 2434 and those assigned by IANA using either the >>>> Standards Action process defined in RFC 2434, or the Early IANA >>>> Allocation process defined in RFC 4020. >>>> >>>> So, as you can see, Dave's proposal *does* include the ability >>>> to use RFC4020 Early IANA Allocation. >>>> >>>> Yakov. >>>> >>> >>> The language in Dave's proposal is a tiny bit ambiguous/confusing. Not >>> necessarily by design, but merely because of limitations of the English >>> language when compound sentences are parsed. >>> >>> Basically, it isn't clear from the proposal language itself, whether >>> what is proposed specifically endorses use of both 2434 *and* 4020 >>> for the process of having IANA assign values. >>> >>> I'd like to see the proposed text (i.e. the literal text that the >>> IDR WG >>> proposes to send to IANA), just so that any ambiguities over how it >>> could be interpreted, are clarified prior to sending it. >>> >>> And, of course, in resolving the ambiguity, obviously I am >>> interested in >>> confirmation that we really do mean "both", e.g.: >>> >>> "The range 0xFFFF8000 to 0xFFFFFFFF is to be assigned by IANA, and >>> requests for IANA assignments are permitted via the process defined >>> in RFC 2434, as well as by the process defined in RFC 4020." >>> >>> (So, yes, I did in fact see the reference to 4020, but just want it >>> much >>> clearer, so that it says what we mean.) >>> >>> Brian >> >> How about the following: >> >> Here is the current definition of the space: >> >> 0x0000000-0x0000FFFF Reserved >> 0xFFFFFF01 NO_EXPORT [RFC1997] >> 0xFFFFFF02 NO_ADVERTISE [RFC1997] >> 0xFFFFFF03 NO_EXPORT_SUBCONFED [RFC1997] >> 0xFFFFFF04 NOPEER [RFC3765] >> 0xFFFF0000-0xFFFFFFFF Reserved >> >> Proposal of redefinition of 0xFFFF0000-0xFFFFFFFF space: >> >> Range Registration Procedures >> ----------- --------------------------------------- >> 0xFFFF0000-0xFFFF8000 First Come First Served >> 0xFFFF8001-0xFFFFFFF Standards Action/Early IANA Allocation >> >> Yakov. >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] WG Last Call on Proposed IANA procedures fo… Yakov Rekhter
- Re: [Idr] WG Last Call on Proposed IANA procedure… Brian Dickson
- Re: [Idr] WG Last Call on Proposed IANA procedure… Brian Dickson
- Re: [Idr] WG Last Call on Proposed IANA procedure… Jeffrey Haas
- Re: [Idr] WG Last Call on Proposed IANA procedure… Brian Dickson
- Re: [Idr] WG Last Call on Proposed IANA procedure… Yakov Rekhter
- Re: [Idr] WG Last Call on Proposed IANA procedure… Thomas M. Knoll
- Re: [Idr] WG Last Call on Proposed IANA procedure… Yakov Rekhter
- Re: [Idr] WG Last Call on Proposed IANA procedure… Cayle Spandon
- Re: [Idr] WG Last Call on Proposed IANA procedure… Yakov Rekhter
- Re: [Idr] WG Last Call on Proposed IANA procedure… Brian Dickson
- Re: [Idr] WG Last Call on Proposed IANA procedure… Yakov Rekhter
- Re: [Idr] WG Last Call on Proposed IANA procedure… David Ward
- Re: [Idr] WG Last Call on Proposed IANA procedure… Tony Li
- Re: [Idr] WG Last Call on Proposed IANA procedure… Brian Dickson