Document: draft-ietf-ccamp-gmpls-segment-recovery-02
Reviewer: Pasi Eronen
Review Date:  September 26, 2006
IETF LC Date: September 20, 2006

Summary: This draft is basically ready for publication (as far as 
I can tell with my limited knowledge of GMPLS and RSVP-TE), but 
has nits that should be fixed before publication.

First a disclaimer: I am not very familiar with GMPLS or RSVP-TE,
so my comments are of rather general nature.

- Since this document defines bits originally marked as "RESERVED" 
  in [E2E-RECOVERY], it probably should be listed in "Updates:" list 
  on the cover page.

- Section 4.1 is a bit unclear on whether it's defining a new
  subobject or modifying something that already exists. Currently, 
  the only explanation is "The protection subobject is not valid 
  for use with the Explicit and Record Route objects and MUST NOT 
  be included in those objects." It might be more understandable 
  to start by explaining where it is valid, and where it can be 
  included.

- Section 9 (IANA considerations) is extremely unclear on what 
  exactly IANA is supposed to do (e.g., in which registry 
  assignments should be made, and what exactly is to be assigned 
  there), and should be rewritten according to the guidelines in 
  Section 5 of draft-narten-iana-considerations-rfc2434bis.

Minor nits:

- Section 2: "0-bit" (zero) probably should be "O-bit" (upper case O)?
- Section 6.1: How will the RFC editor know what to replace "TBA" with?
- References: [RFC2119] should be normative instead of informative.
- References: Document cites RFC2205, but it's not listed here.
- References: [FUNCT] and [TERM], [FRR] are now RFCs, so the
  references should be updated.
- Idnits complains about long lines.