Subject: [Gen-art] Gen-ART LC review of draft-ietf-ccamp-gmpls-segment-recovery-02

From: <[email-masked]>
Date: Tue, 26 Sep 2006 17:02:28 +0300

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call 
comments you may receive.

Document: draft-ietf-ccamp-gmpls-segment-recovery-02
Reviewer: Pasi Eronen
Review Date:  September 26, 2006
IETF LC Date: September 20, 2006
IESG Telechat date: not known yet

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.

Best regards,
Pasi	

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Sep 2006 09:42:37 -0400

Pasi,

Thanks for the comments.  see below for responses in-line.

At 10:11 AM 9/26/2006, [email-masked] wrote:

>(Forwarding with updated email address)

will fix that.

> > -----Original Message-----
> > From: Eronen Pasi (Nokia-NRC/Helsinki)
> > Sent: 26 September, 2006 17:02
> > To: [email-masked]'; [email-masked]';
> > [email-masked]'; [email-masked]';
> > [email-masked]'; [email-masked]';
> > [email-masked]'; [email-masked]'
> > Cc: [email-masked]'
> > Subject: Gen-ART LC review of
> > draft-ietf-ccamp-gmpls-segment-recovery-02
> >
> >

Much thanks for the comments.

> >   in [E2E-RECOVERY], it probably should be listed in "Updates:" list

done.

> >   subobject or modifying something that already exists.

I'm a bit confused on your comment.  If you look at the beginning of 
the section (4) it starts:

    Secondary Explicit Route objects, or SEROs, may be used to indicate
    the branch and merge nodes of recovery LSPs.  They may also provide
    additional information that is to be carried in a recovery LSP's ERO.
    When upstream control of branch and merge nodes is not desired, SEROs
    are not used.

Also earlier in the document, section 2 states:

    [...] This is accomplished using
    a new object.  This object uses the same format as an ERO and is
    referred to as a Secondary Explicit Route object or SERO, see section
    4.1.  SEROs also support a new subobject to indicate the type of
    protection or restoration to be provided.

>Currently,

Okay, I'll some text into 4.1 and 4.1.1 that will hopefully make this 
more clear.

As previously stated,

> >   Section 5 of draft-narten-iana-considerations-rfc2434bis.

Okay, I'll take a look.  BTW This section follows the same recipe as 
I've used in a number of RSVP/MPLS/GMPLS related RFCs and haven't had 
an issue yet.

> > - Section 2: "0-bit" (zero) probably should be "O-bit" (upper case O)?
good catch.

>- Section 6.1: How will the RFC editor know what to replace

The first sentence provides this guidance:
    LSP Segment Recovery Flags are carried in the Protection object of
    the same C-Type defined in [E2E-RECOVERY].

I all add some words on this to the IANA section.

> > - References: [RFC2119] should be normative instead of informative.

done.

> > - References: Document cites RFC2205, but it's not listed here.

done.

> >   references should be updated.

okay.

> > - Idnits complains about long lines.

I'll unicast you a preview of the updated rev to see it you have any 
comments prior to publication.

Much thanks again for the comments,
Lou