Skip to main content

Telechat Review of draft-ietf-ccamp-attribute-bnf-
review-ietf-ccamp-attribute-bnf-secdir-telechat-wierenga-2011-10-14-00

Request Review of draft-ietf-ccamp-attribute-bnf
Requested revision 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
I-D last updated 2011-10-14
Completed reviews Secdir Telechat review of -?? by Klaas Wierenga
Assignment Reviewer Klaas Wierenga
State Completed
Request Telechat review on draft-ietf-ccamp-attribute-bnf by Security Area Directorate Assigned
Completed 2011-10-14
review-ietf-ccamp-attribute-bnf-secdir-telechat-wierenga-2011-10-14-00
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.

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

Regards,

Klaas