Last Call Review of draft-ietf-bfd-intervals-03
review-ietf-bfd-intervals-03-secdir-lc-josefsson-2014-09-04-00
Request | Review of | draft-ietf-bfd-intervals |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2014-09-01 | |
Requested | 2014-08-21 | |
Authors | Nobo Akiya , Marc Binderberger , Greg Mirsky | |
I-D last updated | 2014-09-04 | |
Completed reviews |
Secdir Last Call review of -03
by Simon Josefsson
(diff)
Opsdir Last Call review of -03 by Jürgen Schönwälder (diff) |
|
Assignment | Reviewer | Simon Josefsson |
State | Completed | |
Request | Last Call review on draft-ietf-bfd-intervals by Security Area Directorate Assigned | |
Reviewed revision | 03 (document currently at 05) | |
Result | Has nits | |
Completed | 2014-09-04 |
review-ietf-bfd-intervals-03-secdir-lc-josefsson-2014-09-04-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describe how a flaw in BFD negotiation that can lead to peers failing to agree on a transmission interval can be mitigated by having nodes follow certain conventions. I see no security considerations at all related to this document, and the Security Considerations section adequately reference RFC 5880. Other comments: 1) Why is this document Informational? Not being involved in this area at all, it seems to me that the negotiation flaw is serious enough to warrant 'Updates: 5880' to make sure implementers/deployers read this document. 2) The document refers to RFC 2119 keywords (which are meaningless for non-standards track documents) but the only use of that (that I could find) is in the second paragraph of section 3 which says SHOULD about something that I interpret as being required elsewhere and merely repeated for illustration and background. Section 1 reads 'This document proposes a set of interval values that should be supported by all implementations.' -- I suspect this ought to be SHOULD (or even MUST) instead of 'should'? 3) Pretty please expand the acronym BFD the first time it is is used. Section 1 "Introduction" starts with 'The standard [RFC5880] describes...' and I suggest 'The Bidirectional Forwarding Detection (BFD) standard [RFC5880] describes...' instead. The abstract starts with 'BFD' and I suggest 'Bidirectional Forwarding Detection (BFD)'. Maybe the document title should be changed too, it is now 'Common Interval Support in BFD'. 'Common Interval Support in Bidirectional Forwarding Detection (BFD)' or maybe 'Common Interval Support for the Bidirectional Forwarding Detection (BFD) Protocol'? /Simon Attachment: signature.asc Description: PGP signature