Re: [secdir] Secdir review of draft-ietf-bfd-intervals-03
Simon Josefsson <simon@josefsson.org> Sun, 31 August 2014 19:37 UTC
Return-Path: <simon@josefsson.org>
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 1F8591A8BB1; Sun, 31 Aug 2014 12:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
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 QK2VAoWQrYIo; Sun, 31 Aug 2014 12:37:57 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D201A8AFE; Sun, 31 Aug 2014 12:37:56 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7VJbkBq015489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 31 Aug 2014 21:37:47 +0200
Date: Sun, 31 Aug 2014 21:37:44 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Marc Binderberger <marc@sniff.de>
Message-ID: <20140831213744.3dc0fcff@latte.josefsson.org>
In-Reply-To: <20140831114409097014.277d3630@sniff.de>
References: <20140830170942319588.ce02d0f5@cisco.com> <20140831114409097014.277d3630@sniff.de>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
OpenPGP: id=54265e8c; url=http://josefsson.org/54265e8c.txt
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="PGP-SHA256"; boundary="Sig_//xecfQgaLUvA68XLklujD7P"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/n7wE5NR28-9zUPSY9Dk9smzMAOY
Cc: Gregory Mirsky <gregory.mirsky@ericsson.com>, "Nobo Akiya (nobo)" <nobo@cisco.com>, draft-ietf-bfd-intervals.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] 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 19:37:59 -0000
Thanks for response. If the standards track issue has already been discussed by authors and WG, then I'm happy -- I just wanted to bring it up in case it hadn't already been discussed. /Simon You wrote: > 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