Skip to main content

Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-12

Discuss


Yes

(Deborah Brungard)

No Objection

(Magnus Westerlund)
(Mirja Kühlewind)
(Suresh Krishnan)

No Record

Andrew Alston
Erik Kline
Francesca Palombini
John Scudder
Lars Eggert
Martin Duke
Murray Kucherawy
Paul Wouters
Robert Wilton
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES. Needs 8 more YES or NO OBJECTION positions to pass.

Alvaro Retana (was Discuss) No Objection

Comment (2020-12-18 for -10)
[Thank you for addressing my DISCUSS.]

Roman Danyliw No Objection

Comment (2019-12-05 for -07)
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.

Andrew Alston No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Lars Eggert No Record

Martin Duke No Record

Murray Kucherawy No Record

Paul Wouters No Record

Robert Wilton No Record

Warren Kumari No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Benjamin Kaduk; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2020-11-17 for -08)
[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 steering group member) Yes

Yes (for -07)

                            

(Adam Roach; former steering group member) No Objection

No Objection (2019-12-04 for -07)
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  > document are to be interpreted as described in RFC-2119 [RFC2119].

Please update to use the boilerplate specified by RFC 8174.

(Alissa Cooper; former steering group member) No Objection

No Objection (2019-12-03 for -07)
Please respond to the Gen-ART review.

(Barry Leiba; former steering group member) No Objection

No Objection (2019-12-04 for -07)
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 steering group member) No Objection

No Objection (for -07)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -07)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -07)