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

[Lou Berger <[e-mail]>]

Pasi,

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

At 10:11 AM 9/26/2006, [e-mail] wrote:

>(Forwarding with updated email address)

will fix that.

> > -----Original Message-----
> > From: Eronen Pasi (Nokia-NRC/Helsinki)
> > Sent: 26 September, 2006 17:02
> > To: '[e-mail]'; '[e-mail]';
> > '[e-mail]'; '[e-mail]';
> > '[e-mail]'; '[e-mail]';
> > '[e-mail]'; '[e-mail]'
> > Cc: '[e-mail]'
> > Subject: Gen-ART LC review of
> > draft-ietf-ccamp-gmpls-segment-recovery-02
> >
> >
> > 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.
> >

Much thanks for the comments.

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

done.

> >
> > - Section 4.1 is a bit unclear on whether it's defining a new
> >   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,
> >   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.

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

As previously stated,

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

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.

> > Minor nits:
> >
> > - 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
> > "TBA" with?

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: [FUNCT] and [TERM], [FRR] are now RFCs, so the
> >   references should be updated.

okay.

> > - Idnits complains about long lines.
> >
> > Best regards,
> > Pasi

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


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