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

Note: This ballot was opened for revision 07 and is now closed.

Alvaro Retana Yes

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-05-13)
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.

Erik Kline No Objection

Martin Duke No Objection

Comment (2020-04-30 for -08)
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?

Martin Vigoureux No Objection

Comment (2020-05-06 for -08)
No email
send info
I have the same concerns than some of the other ADs so no need to restate them here.

Murray Kucherawy No Objection

Robert Wilton No Objection

Comment (2020-05-04 for -08)
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

Comment (2020-05-05 for -08)
No email
send info
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

Comment (2020-05-06 for -08)
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

No Objection (2020-05-06 for -08)
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

No Objection (2020-05-05 for -08)
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.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection (2020-05-12)
Thanks for addressing the issues I raised.