Ballot for draft-ietf-mpls-ri-rsvp-frr
Discuss
Yes
No Objection
No Record
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
Section 5. Recommend adding language about using more modern HMAC algorithms than those suggested in RFC2747. For example: OLD: The security considerations pertaining to the original RSVP protocol [RFC2205], [RFC3209] and [RFC5920] remain relevant. NEW: The security considerations pertaining to the original RSVP protocol [RFC2205], [RFC3209] and [RFC5920] remain relevant. When using RSVP Cryptographic Authentication [RFC2747], more robust algorithms such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA-512 [RFC2104][SHS] SHOULD be used when computing the keyed message digest where possible. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [SHS] National Institute of Standards and Technology (NIST), FIPS Publication 186-3: Digital Signature Standard, October 2008.
[no significant changes from -07 to -08, so refreshing what version the datatracker thinks this position applies to] I think there's a lot of SHOULDs in this document that, if ignored, would cause the implementation to fail to achieve its stated purpose (elimination of stale state retention). Therefore, I don't understand why they are given as SHOULD rather than MUST. I have noted many (but probably not all) such instances in the COMMENT section.
Please respond to the Gen-ART review.
[Thank you for addressing my DISCUSS.]
There are numerous problems with the use and absence of articles (“the”, “a”, “an”) throughout the document: articles are missing when they should be there, “the” is used when an indefinite article should be, and so on. That made it a harder read than it should have been. The RPC will fix it during editing, but maybe the AD should add an RFC Editor Note to alert them to be particularly watchful for these issues.