Re: [secdir] secdir review of draft-ietf-ccamp-attribute-bnf-02.txt

[Lou Berger <[e-mail]>]

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