[Idr] Can we eliminate the "IETF Review" Capablities range? [was: Re: I-D Action: draft-ietf-idr-capabilities-registry-change-04.txt]

[John Scudder <[e-mail]>]

Hi All,

On May 23, 2019, at 12:53 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-04.txt
Pages           : 5
Date            : 2019-05-23

This is a version bump to refresh the draft, which had expired. There are two outstanding points I can think of:

1. I’ve received a report of another use of Capability 129 (different from the one reported in the draft). I’m following up with the reporter to find out if that needs to be documented in the draft, if it does I’ll issue a revision.

2. The draft currently leaves Capabilities 1-63 as “IETF Review”. As I’ve mentioned in another thread recently, I’ve become skeptical of the value of splitting registries between IETF Review and FCFS. Here are some options, listed in order of my own preference:

2.a. Make 1-238 all FCFS.
Pro: this is the easiest allocation policy with the least admin overhead. There is no decision required as to which range to select, so less confusion.
Con: there’s a theoretical risk of the number space being completely consumed, without any formal way for the WG to prevent it. (A “run on the bank”.)
Rebuttal: this hasn’t been seen to happen in practice. Also, we do reserve 255 in case we need it for future extension.

2.b. Make 1-63 Reserved, 64-238 FCFS.
Pro: as above, but without the chance that the number space could be completely consumed since 1-63 is protected. If that range is needed in the future, another draft can be written to reclassify it as IETF Review again, or as whatever is desired at that time.
Con: it’s a slightly more complicated solution to what may be a non-problem.

2.c. Leave it as written in version 04, 1-63 IETF Review, 64-238 FCFS.
Pro: it’s what we’ve already been discussing and nobody (other than me, in this note) has raised an objection so far.
Con: authors are required to choose between the two ranges, experience shows that many assume that IETF Review is “better” for some reason. This holds up number allocation, retards implementation, and invokes additional administrative overhead without returning any concrete benefit.

I’d be interested in discussion of these options. Once these points are settled IMO the draft is ready for last call.

Thanks,

—John