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

[David Ward <[e-mail]>]

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

-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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr