[Gen-art] Re: Gen-ART review of draft-ietf-ospf-cap-09.txt

Acee Lindem <acee@cisco.com> Tue, 28 November 2006 20:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9nB-0006a6-Iq; Tue, 28 Nov 2006 15:43:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9lg-0004r2-Ta for gen-art@ietf.org; Tue, 28 Nov 2006 15:41:28 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9lf-0002bB-H2 for gen-art@ietf.org; Tue, 28 Nov 2006 15:41:28 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 28 Nov 2006 12:41:26 -0800
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kASKfPd8012347; Tue, 28 Nov 2006 15:41:26 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASKfPDO011784; Tue, 28 Nov 2006 15:41:25 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 15:41:25 -0500
Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 15:41:24 -0500
Message-ID: <456C9EF3.2080307@cisco.com>
Date: Tue, 28 Nov 2006 15:41:23 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Black_David@emc.com
References: <F222151D3323874393F83102D614E05502B67647@CORPUSMX20A.corp.emc.com>
In-Reply-To: <F222151D3323874393F83102D614E05502B67647@CORPUSMX20A.corp.emc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Nov 2006 20:41:24.0570 (UTC) FILETIME=[91E7EBA0:01C7132D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3476; t=1164746486; x=1165610486; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20<acee@cisco.com> |Subject:=20Re=3A=20Gen-ART=20review=20of=20draft-ietf-ospf-cap-09.txt |Sender:=20 |To:=20Black_David@emc.com; bh=1FUYe5tgCfUFslNNEChNY7nZOTSK1MzcVCO+2/oNoKQ=; b=ijO5BKwyWd8mAAqrWrtU5JKDJNfXJycH9pKZ8BlC4Fzb6wOwNr48i7Xj1d636dYBpRtEWEeU lA/Ffzhe1Yd5eOD1ORmlByxXnzYVHT6C9AkajfO4oIfD1G0KpUO7C37X;
Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
X-Mailman-Approved-At: Tue, 28 Nov 2006 15:43:00 -0500
Cc: fenner@research.att.com, gen-art@ietf.org, dube.rohit@gmail.com, jpv@cisco.com, naiming@cisco.com, rahul@juniper.net, sshafferl@bridgeport-networks.com
Subject: [Gen-art] Re: Gen-ART review of draft-ietf-ospf-cap-09.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

Hi David,
Thanks for the review. All your comments will be in the -10 version of the
document. Here is my new text for the "Security Considerations" section:

4.  Security Considerations

   This document describes both a generic mechanism for advertising
   router capabilites and a TLV for advertising informational capability
   bits.  The latter TLV is less critical than the topology information
   currently advertised by the base OSPF protocol.  The security
   considerations for the generic mechanism are dependent on the future
   application and, as such, should be described as additional
   capabilities are proposed for advertisement.  Security considerations
   for the base OSPF protocol are covered in [OSPF] and [OSPFV3].




Thanks,
Acee 




































Lindem (Editor), et al.   Expires June 1, 2007         


Black_David@emc.com wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document:
>     Extensions to OSPF for Advertising Optional Router Capabilities
>                        draft-ietf-ospf-cap-09.txt
> Reviewer: David L. Black
> Review Date: October 29, 2006
> IETF LC Date: Ends November 6, 2006
>
> Summary:
> This draft is basically ready for publication, but has nits
> that should be fixed before publication.
>
> Comments:
> This draft describes a small addition of bits to advertise
> optional capabilities to OSPF.  All of the items in this
> review are editorial in nature.
>
> Section 3 - The use of "MUST" in the following sentence is not
> appropriate, as this is a design requirement, not a protocol
> requirement:
>
>    Hence, discretion
>    and sound engineering judgment MUST be adhered to when deciding
>    whether newly proposed TLV(s) in support of a new application are
>    advertised in the RI LSA or warrant the creation of an application
>    specific LSA.
>
> A lower case "must" would suffice, but a rephrasing to emphasize the
> importance of this design concern in work on such TLVs would be better.
>
> Section 4: The security considerations statement that this document
> does not create any new security issues for the OSPF protocol is
> too narrow.  The advertisement of capabilities may provide useful
> information to an attacker looking for a particular feature or
> vulnerability to attack.  No new OSPF security countermeasures
> should be necessary, and it may be ok to refer discussion of this
> issue to the existing OSPF RFCs if it is adequately covered there,
> but the statement that there are no security considerations in the
> functional content of this draft is not correct.
>
> Section 5: Please tell IANA what the content of an entry is in
> each of the new registries - saying that their fields are the
> same as an existing registry is among the ways to do this.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>   

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art