Re: [secdir] Fwd: Secdir review of draft-ietf-bfd-intervals-03

[Marc Binderberger <[e-mail]>]

Hello Simon,

thanks for the review!

Let me start with the simple part:

> 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.
>	[...]

Good point. In fact a not-yet-published updated draft contains your first 
example already; I will add your other suggestions as well.


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

This was discussed in the BFD workgroup and the consensus was the set of 
"Common Intervals" should be more a guideline for developers and not a strict 
requirement. I personally think the availability of the document to the 
public, including customers, will create enough momentum for implementers to 
read this.

Appendix B is on the border, IMHO. The underlying mechanism is still the same 
Poll sequence as defined in RFC5880, we just clarify how to apply it in a 
multi-step convergence. And yes, RFC5880 has a "gap" in assuming the 
convergence takes only one poll sequence. Again the workgroup seems to be 
fine to have this additional information informal.


> 2) The document refers to RFC 2119 keywords (which are meaningless for
> non-standards track documents)

you have a point but as we use this one SHOULD I thought it's good to have 
this reference.


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

We moved away from MUST to SHOULD when we decided the draft should have an 
informal status. I reduced it to the one SHOULD in section 3 as this is the 
only section that spells out a technical requirement; the other sections 
explain the problem and the solution idea, which is why I used normal English 
"should", "may", "recommend" for these sections.

Kind of: getting the readers attention in section 3 as these paragraphs need 
to be read more carefully. 


Let me incorporate your proposed changes and I send you a diff to check I do 
address your comments properly.


Again thanks for the review!

Best regards,
Nobo, Greg & Marc



> 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