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

From: [email-masked]
Date: Tue, 13 Nov 2018 12:13:33 -0800

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".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-capabilities-registry-change-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-capabilities-registry-change-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-capabilities-registry-change-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: John Scudder <[email-masked]>
Date: Tue, 13 Nov 2018 20:16:07 +0000

Hi All,

Acee informs me that

On Nov 13, 2018, at 2:43 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> 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, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

---

From: tom petch <[email-masked]>
Date: Thu, 15 Nov 2018 10:36:01 +0000

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!

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.

Tom Petch

----- Original Message -----
From: "John Scudder" <[email-masked]>
To: <[email-masked]>
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)
<[email-masked]<mailto:[email-masked]>> wrote:

Prior to 2007, we did, in fact, send the 129 capability in external
releases of IOS 12.0

--John

On Nov 13, 2018, at 3:13 PM,
[email-masked]<mailto:[email-masked]> 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:

------------------------------------------------------------------------
--------

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: John Scudder <[email-masked]>
Date: Thu, 15 Nov 2018 17:35:56 +0000

Hi Tom,

> On Nov 15, 2018, at 5:36 AM, tom petch <[email-masked]> wrote:
> 
> John
> 

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.

> 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

>> 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=
>> 
>

---

From: tom petch <[email-masked]>
Date: Fri, 16 Nov 2018 12:24:17 +0000

----- Original Message -----
From: "John Scudder" <[email-masked]>
To: "tom petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 15, 2018 5:35 PM

Hi Tom,

> 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.

<tp>
John

Looking better.  You will at some point IMHO need to change

"   Finally, we invite implementors who have used values in the range
   128-255 to contribute to this draft,"

I think that what is lacking is a reference back for the new FCFS code
points.

Look at
'Address Family Numbers' group, not a million miles from BGP, and you
find FCFS with e.g.
16384 EIGRP Common Service Family [Donnie_Savage]
16387 LISP Canonical Address Format (LCAF) [David_Meyer]
so that at any time in the future, may be 10 or 20 years hence, IANA can
see where that came from.

For this registry, the reference for
128 Prestandard Route Refresh (deprecated)
129 Prestandard Outbound Route Filtering
130 Prestandard Outbound Route Filtering
is not really this I-D but the e-mails that you have exchanged with Acee
etc.

So two ideas; one is to put the names/e-mail addresses of the people who
have given you the information into the registration in s.3.  The people
concerned may not want to use their own e-mail addresses but a company
designated one but some name/function and e-mail address is needed IMHO
as a reference for IANA.

Alternatively, which I prefer, you make the I-D the reference but then
include the information in the I-D so the text I quote above becomes
something like

"  In the course of the preparation of this memo, implementors who have
used values in the range 128-255 were invited to register them.  This
yielded the following values
128....
129 Prior to 2007, Cisco sent the 129 capability in external releases of
IOS 12.0
130 .....  "

If anyone is concerned about privacy and might think this is exposing
too much information, well, remember 'Note Well' - anything in an e-mail
can be reused in this way.  Or again, if you want FCFS in future, then
you have to identify yourself to IANA and IANA will put that information
on the website!

Tom Petch

> 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