Re: [secdir] secdir review of draft-ietf-ccamp-attribute-bnf-02.txt
"Adrian Farrel" <adrian@olddog.co.uk> Fri, 14 October 2011 19:31 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32921F8C83 for <secdir@ietfa.amsl.com>; Fri, 14 Oct 2011 12:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km-7pZoMwNtf for <secdir@ietfa.amsl.com>; Fri, 14 Oct 2011 12:31:53 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 434C021F8C9E for <secdir@ietf.org>; Fri, 14 Oct 2011 12:31:48 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9EJVjip006811; Fri, 14 Oct 2011 20:31:45 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9EJVhCf006802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Oct 2011 20:31:44 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Lou Berger' <lberger@labn.net>, 'Klaas Wierenga' <klaas@cisco.com>
References: <CB75297E-A65B-4D16-B09A-DD16A7F79CC1@cisco.com> <4E9888CB.1080208@labn.net>
In-Reply-To: <4E9888CB.1080208@labn.net>
Date: Fri, 14 Oct 2011 20:31:43 +0100
Message-ID: <041001cc8aa7$e849e470$b8ddad50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-language: en-gb
Thread-index: AQKevjEplp2bVEy5uX6OVXzUjvMlegG/Eeq5k8naLxA=
Cc: draft-ietf-ccamp-attribute-bnf@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-ccamp-attribute-bnf-02.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Fri, 14 Oct 2011 19:31:54 -0000
RFC Editors notes added. Adrian > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 14 October 2011 20:09 > To: Klaas Wierenga > Cc: secdir@ietf.org; draft-ietf-ccamp-attribute-bnf@tools.ietf.org; Adrian Farrel > Subject: Re: secdir review of draft-ietf-ccamp-attribute-bnf-02.txt > > Klaas, > Thank you for the comments. Please see responses in-line below. > > Lou > > On 10/14/2011 11:06 AM, Klaas Wierenga wrote: > > Hi, > > > > 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 (short) document specifies how LSP (Label Switched Path) > > attributes are to be carried in RSVP Path and Resv messages using the > > Routing Backus-Naur Form, and clarifies related Resv message formats. > > The document updates RFC 4875 and RFC 5420. Section 9 of RFC5420 > > contains a narrative description of the message formats for the > > definition of the object carrying information on the LSP. This > > document provides the BNF for Path and Resv messages carrying the LSP > > Attributes related object. > > > > Given my lack of expertise in MPLS I have not much to offer in terms > > of general comments on the draft for the draft authors to take into > > consideration, but here goes: > > > > - Section 1 > > > > Gives a short explanation as to why you need to update 5420, but not > > why the same goes for 4875, this may be obvious for most, but it was > > not for me. I think it would help to add a sentence on the necessary > > changes for 4875. > > > > I think this is obvious to any involved in the technology, but how about: > OLD: > processed in Resv messages of P2MP LSPs. > NEW > processed in Resv messages of P2MP LSPs (which are defined in > [RFC4875]). > > > > - Section 1, p3 states: "The current message format description has > > led to an issue in how the LSP Attributes related objects are to be > > processed in Resv messages of P2MP LSPs." > > > > Is this just the fact that the lack of a formal definition of the > > message format leads to inconstant implementations? If so, why not > > state just that? If not, what is the problem? > > > > How about: > OLD: > The current message format description has led > to an issue in how the LSP Attributes related objects are to be > processed... > NEW > The current message format description has led to the open > question of how the LSP Attributes related objects are to be > processed... > > Thanks, > Lou > > > > - The security considerations section states: "This document > > clarifies usage of objects defined in [RFC5420]. No new information > > is conveyed and therefore neither are there any additional security > > considerations. " > > > > Which I think that is a fair statement. So concerning the security > > considerations part I see no objection for this document to advance. > > > > Regards, > > > > Klaas > > > > > > > > > > > > > >
- [secdir] secdir review of draft-ietf-ccamp-attrib… Klaas Wierenga
- Re: [secdir] secdir review of draft-ietf-ccamp-at… Lou Berger
- Re: [secdir] secdir review of draft-ietf-ccamp-at… Adrian Farrel