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

["Adrian Farrel" <[e-mail]>]

RFC Editors notes added.

Adrian

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: 14 October 2011 20:09
> To: Klaas Wierenga
> Cc: [e-mail]; [e-mail]; 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
> >
> >
> >
> >
> >
> >
> >