Last Call Review of draft-ietf-ccamp-pc-spc-rsvpte-ext-
review-ietf-ccamp-pc-spc-rsvpte-ext-secdir-lc-wallace-2010-02-02-00

Request Review of draft-ietf-ccamp-pc-spc-rsvpte-ext
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-02-02
Requested 2010-01-14
Authors Snigdho Bardalai, Diego Caviglia, Daniele Ceccarelli, Dan Li
Draft last updated 2010-02-02
Completed reviews Secdir Last Call review of -?? by Carl Wallace
Assignment Reviewer Carl Wallace
State Completed
Review review-ietf-ccamp-pc-spc-rsvpte-ext-secdir-lc-wallace-2010-02-02
Review completed: 2010-02-02

Review
review-ietf-ccamp-pc-spc-rsvpte-ext-secdir-lc-wallace-2010-02-02

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 draft describes an extension to GMPLS RSVP-TE signaling that
enables the transfer of connection ownership between the Management and
the Control Planes.  Generally, the draft seems to cover relevant
possible failures and references another draft (sec-fwk) that provides
additional security considerations.  My primary comment on the draft is
that it was not clear to me how section 5 related to the steps in
section 4.  Bearing in mind that I am not familiar with RSVP, it seems
like there could be one set of procedures that accommodate the two
options for retrieving information.  As written, some portions of the
steps in section 4 appear to be generic, i.e., "Each LSR that receives a
Path message with the H bit set...", while other portions of section 4
appear to limit the applicability of the steps to cases where the ERO
method is used, i.e., "In this mode of handover, the Path message also
carries an ERO...".  Section 5 also allows an ERO to be optionally
included.