Re: [Idr] WG Last Call on Proposed IANA procedures for BGP Well-known communities

Brian Dickson <briand@ca.afilias.info> Tue, 12 August 2008 20:14 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 F038D3A6C82; Tue, 12 Aug 2008 13:14:41 -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 9A01C3A6C80 for <idr@core3.amsl.com>; Tue, 12 Aug 2008 13:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.758
X-Spam-Level:
X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.841, 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 cX4FAx7wc6Zz for <idr@core3.amsl.com>; Tue, 12 Aug 2008 13:14:39 -0700 (PDT)
Received: from vgateway.libertyrms.info (vgateway.libertyrms.info [207.219.45.62]) by core3.amsl.com (Postfix) with ESMTP id AD3FD3A6C82 for <idr@ietf.org>; Tue, 12 Aug 2008 13:14:39 -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 1KT0GE-00011O-2l; Tue, 12 Aug 2008 16:14:30 -0400
Message-ID: <48A1EF25.3080606@ca.afilias.info>
Date: Tue, 12 Aug 2008 16:14:29 -0400
From: Brian Dickson <briand@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Yakov Rekhter <yakov@juniper.net>
References: <200808121939.m7CJdJu33721@magenta.juniper.net>
In-Reply-To: <200808121939.m7CJdJu33721@magenta.juniper.net>
X-SA-Exim-Mail-From: briand@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Cc: 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

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
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr