Telechat Review of draft-ietf-ccamp-attribute-bnf-

Request Review of draft-ietf-ccamp-attribute-bnf
Requested rev. no specific revision (document currently at 02)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2011-10-14
Requested 2011-10-07
Authors George Swallow, Lou Berger
Draft last updated 2011-10-14
Completed reviews Secdir Telechat review of -?? by Klaas Wierenga
Assignment Reviewer Klaas Wierenga 
State Completed
Review review-ietf-ccamp-attribute-bnf-secdir-telechat-wierenga-2011-10-14
Review completed: 2011-10-14



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.

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

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