Re: [secdir] Fwd: Secdir review of draft-ietf-bfd-intervals-03
Marc Binderberger <marc@sniff.de> Sun, 31 August 2014 18:44 UTC
Return-Path: <marc@sniff.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FDA1A8AD6; Sun, 31 Aug 2014 11:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level:
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVn_jfuiXOTz; Sun, 31 Aug 2014 11:44:07 -0700 (PDT)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0930D1A8AD1; Sun, 31 Aug 2014 11:44:07 -0700 (PDT)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 8FE4F2AA0F; Sun, 31 Aug 2014 18:44:03 +0000 (GMT)
Date: Sun, 31 Aug 2014 11:44:09 -0700
From: Marc Binderberger <marc@sniff.de>
To: Simon Josefsson <simon@josefsson.org>, Nobo Akiya <nobo@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>
Message-ID: <20140831114409097014.277d3630@sniff.de>
In-Reply-To: <20140830170942319588.ce02d0f5@cisco.com>
References: <20140830170942319588.ce02d0f5@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.15
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/t_X_9k5JBRlsxkDdqr4HAdReeIw
X-Mailman-Approved-At: Tue, 02 Sep 2014 08:01:24 -0700
Cc: draft-ietf-bfd-intervals.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Fwd: Secdir review of draft-ietf-bfd-intervals-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 18:44:09 -0000
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
- [secdir] Secdir review of draft-ietf-bfd-interval… Simon Josefsson
- Re: [secdir] Secdir review of draft-ietf-bfd-inte… Simon Josefsson
- Re: [secdir] Fwd: Secdir review of draft-ietf-bfd… Marc Binderberger