Skip to main content

Last Call Review of draft-ietf-bfd-intervals-03

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
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

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'?





 PGP signature