Re: [Idr] I-D Action: draft-ietf-idr-capabilities-registry-change-02.txt

[John Scudder <[e-mail]>]

Hi Tom,

> On Nov 15, 2018, at 5:36 AM, tom petch <[e-mail]> wrote:
> 
> John
> 
> An admin detail.  I would suggest wording the request as
> 
>   IANA is requested to revise the registration procedures for the
>   "Capability Codes" registry
> in the Border Gateway Protocol Parameters group
> 
> so as to distinguish it from the
> BGP Monitoring Protocol (BMP) Parameters group
> or the
> Border Gateway Protocol - Link State (BGP-LS) Parameters group
> I like to keep these things simple!

I had considered this but was thrown off by the fact that some, but not all, BGP parameters are listed on a single IANA page headlined "Border Gateway Protocol (BGP) Parameters", but Capabilities are off on a different one headlined "Capability Codes". However, upon reviewing RFC 8126 section 2.1 ("Organization of Registries") I see that the authoritative way to determine what's in and what's out for a protocol group is to consult https://www.iana.org/protocols, which does indeed list Capability Codes under "Border Gateway Protocol (BGP) Parameters".

I've made the update you suggest. However, as part of reviewing RFC 8126 (not exhaustively!) I noticed IANA wants to be told what the change control procedures are (8126 sections 2.3, 4.4, and 9.5), and that led me down a rabbit hole. I've updated the document as I *think* 8126 wants me to. As I've written it, the change controller (or "owner") is always IESG. This implies (I think!) that though you can register a code point in the FCFS range with no meaningful process requirements, it's write-once -- once you've done so, you can't revise your registration. In the case of the description field this seems a bit arbitrary until you consider that a change might be to add "(deprecated)", for example. And in the case of the reference field, consider the request "oh this code point used to be used as per draft-foo-bar-01 but now you should reference incompatible draft-foo-bar-02". My intention is that by writing it this way we provide a quick/easy/transparent way for WG members to get code points when they need (our main goal with FCFS, IMO) while subsequently providing most of the stability we hope to get when we use IETF Action or even Specification Required. Oh, and my understanding is that by putting "IESG" as the owner, that means the WG can still make changes as needed, by progressing a draft to RFC -- just like this one.
 
(As an aside, I notice that some registries have a "contact" field distinct from the "reference" field, but we don't, at least not in the ones I've spot-checked.)

Anyway, I'd appreciate further review and comment, because the whole thing makes my head hurt.

> Also, since the registry will now say
> 255   Reserved
> I would add
> 0 Reserved
> 
> It looks odd to mention 255 and not 0 when both have the same standing.

I've made this change too. I note that 0 was already listed as Reserved in the registry itself, so I added that for 255, too. It seems a little funny to do it in both places but you're right that we should be consistent. 

I've posted -03 for review. I expect there may well need to be (at least) an -04 as a result of discussion.

Thanks for helping me "keep these things simple". I'd hate to think what they'd be like if they were complicated! ;-)

--John

> 
> Tom Petch
> 
> ----- Original Message -----
> From: "John Scudder" <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, November 13, 2018 8:16 PM
> 
> Hi All,
> 
> Acee informs me that
> 
> On Nov 13, 2018, at 2:43 PM, Acee Lindem (acee)
> <[e-mail]<mailto:[e-mail]>> wrote:
> 
> Prior to 2007, we did, in fact, send the 129 capability in external
> releases of IOS 12.0
> 
> in light of this I've added 129 to the registered-and-deprecated list.
> 
> Thanks, to Acee and Juan Alcaide for doing the investigation.
> 
> --John
> 
> On Nov 13, 2018, at 3:13 PM,
> [e-mail]<mailto:[e-mail]> wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
> 
>       Title           : Revision to Capability Codes Registration
> Procedures
>       Author          : John Scudder
> Filename        : draft-ietf-idr-capabilities-registry-change-02.txt
> Pages           : 4
> Date            : 2018-11-13
> 
> Abstract:
>  This document updates RFC 5492 by making a change to the registration
>  procedures for BGP Capability Codes.  Specifically, the range
>  formerly designated "Reserved for Private Use" is divided into three
>  new ranges, respectively designated as "First Come First Served",
>  "Experimental" and "Reserved".
> 
> 
> 
> 
> ------------------------------------------------------------------------
> --------
> 
> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=9XSKSF3VbBUO2kPoFyqPmXj_kw1VpVAyL47LjIDHQQA&s=O2d2hgBZU4vdD5zpo-QSH7_gjjMyaHIxy9J8uMsf_zE&e=
>> 
>