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

From: Yakov Rekhter <[email-masked]>
Date: Tue, 12 Aug 2008 12:39:19 -0700

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

---

From: Brian Dickson <[email-masked]>
Date: Tue, 12 Aug 2008 16:14:29 -0400

> to use RFC4020 Early IANA Allocation.

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

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 12 Aug 2008 17:22:28 -0700

Brian,

> necessarily by design, but merely because of limitations of the English 
> language when compound sentences are parsed.
> 
> what is proposed specifically endorses use of both 2434 *and* 4020 
> for the process of having IANA assign values.
> 
> proposes to send to IANA), just so that any ambiguities over how it 
> could be interpreted, are clarified prior to sending it.
> 
> confirmation that we really do mean "both", e.g.:
> 
> requests for IANA assignments are permitted via the process defined 
> in RFC 2434, as well as by the process defined in RFC 4020."
> 

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.

---

From: David Ward <[email-masked]>
Date: Tue, 12 Aug 2008 23:36:31 -0500

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

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Aug 2008 02:00:08 -0400

David Ward wrote:
> 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.
>

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