Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-16
Discuss
Yes
(Deborah Brungard)
No Objection
(Magnus Westerlund)
(Mirja Kühlewind)
(Suresh Krishnan)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
Roman Danyliw
No Objection
Comment
(2019-12-05 for -07)
Sent
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.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Benjamin Kaduk Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2020-11-17 for -08)
Sent for earlier
[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.
Deborah Brungard Former IESG member
Yes
Yes
(for -07)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2019-12-04 for -07)
Sent
Alissa Cooper Former IESG member
No Objection
No Objection
(2019-12-03 for -07)
Sent
Please respond to the Gen-ART review.
Alvaro Retana Former IESG member
(was Discuss)
No Objection
No Objection
(2020-12-18 for -10)
Sent for earlier
[Thank you for addressing my DISCUSS.]
Barry Leiba Former IESG member
No Objection
No Objection
(2019-12-04 for -07)
Sent
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.
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -07)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -07)
Not sent
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -07)
Not sent