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