Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[John Scudder <[e-mail]>]

> On Jan 12, 2023, at 1:43 PM, Jeffrey Haas <[e-mail]> wrote:
> 
>> On Jan 12, 2023, at 1:24 PM, John Scudder <[e-mail]> wrote:
>> 
>> FWIW, as far as I know, the behavior permitted by the paragraph you quote has never been used. If that’s true, it might not be a bad idea to do an update of RFC 5492 that removes the paragraph and deprecates the Unsupported Capability error code entirely, to avoid future generations going through the same confusion. If the WG wants to do this, I’d be willing to participate, although the first step would be to do a survey to make sure nobody actually is making use of the feature and I’d want someone else to lead on that.
> 
> The example cited, "I really want ipv6", is a good motivation for "negotiate this, or hang up".  I don't think we'll ever want it gone from the spec.

That is fine (and less work for me, yay).

Just to pick at it a little more, though — if we did deprecate Unsupported Capability, there’s no reason a future spec couldn’t be written and progressed, that re-introduced the functionality, along with a better-named error code, for example “Missing Required Capability”. The benefit being, instead of having to dumpster-dive for an unused feature in an old RFC, you’d be speccing out the functionality when the requirement was fresh. Even if it was specced out exactly as it was before, there might be some benefit in doing it that way.

For that matter, I guess we could write and progress a one-pager to simply rename “Unsupported Capability” as “Missing Required Capability” in the registry, along with a corresponding Update: to the nomenclature in 5492. I can’t remember now why we didn’t do this when we published 5492. It’s not clear to me if even this small effort is warranted, but maybe the problem is still prevalent enough that it could be worthwhile, I don’t know.

—John