Revision to Capability Codes Registration Procedures
draft-ietf-idr-capabilities-registry-change-09

I support Ben Kaduk’s DISCUSS position.  With the caveat that I don’t have a sense of existing implementations, restating Ben's concern, it seems like there should be some discussion of (or exclusion of) the possibility that someone relied on what was previously a private code point which may now be registered for others use with different semantics.

Easy to read document and while looking straightforward, I believe that Ben Kaduk and Magnus have raised a valid DISCUSS to be addressed. If section 3 content is exhaustive, then this would solve their DISCUSS probably.

Finally, https://www.iana.org/assignments/capability-codes/capability-codes.xhtml seems to indicate that there are still many code points available for first come, first use. So, perhaps no need to carve out another FCFS code points block.

Regards

-éric

I agree with Magnus that the values being registered in Section 3 need a bit of explanation.

Other comments have already said that the document should discuss the implementation survey that was apparently done.  I agree with that.  Otherwise, just one minor editorial nit:

— Abstract —
The word “respectively” doesn’t belong here, because there isn’t a prior list to relate the designations to (contrast this with the last sentence in the Introduction, where it is used correctly).  Just remove the word.

Thanks for addressing my discuss; it's not quite how I would have done it,
but the key point is clearly covered, so that's good enough for me.

Thanks for addressing the issues I raised.

In section 3, it would be nice to have a sentence about the motivation for the new registry entries.

Should 255 be in table 1 as well as table 2?

I have the same concerns than some of the other ADs so no need to restate them here.

This document is straight forward and easy to read and understand.  I had one minor comment.

   [RFC5492] designates the range of Capability Codes 128-255 as
   "Reserved for Private Use".  Subsequent experience has shown this to
   be not only useless, but actively confusing to implementors.

It might possibly be helpful to expand this paragraph slightly.

Because what was once "Reserved for Private Use" is now being reclassified to something non private, I presume that there are no BGP implementations using these capability codes that could be broken by this reclassification.  Hence, on the assumption that these codes are not in fact being used for private use, it might be helpful to state that in order to help justify why it is okay to make this change.