Revision to Capability Codes Registration Procedures
RFC 8810
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana Yes
Erik Kline No Objection
Martin Duke No Objection
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?
Murray Kucherawy No Objection
Robert Wilton No Objection
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.
Roman Danyliw No Objection
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.
Warren Kumari No Objection
Éric Vyncke No Objection
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
(Alissa Cooper; former steering group member) No Objection
I agree with Magnus that the values being registered in Section 3 need a bit of explanation.
(Barry Leiba; former steering group member) No Objection
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.
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
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.
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
Thanks for addressing the issues I raised.
(Martin Vigoureux; former steering group member) No Objection
I have the same concerns than some of the other ADs so no need to restate them here.