Document: draft-ietf-ccamp-pc-spc-rsvpte-ext-06
Reviewer: Ben Campbell
Review Date: 1 Feb 2010
IESG Telechat date: 4 Feb 2010

Summary: This draft is almost ready for publication as a draft standard, 
but  I think there are a few issues that need clarification first, as 
well as some editorial issues.

Note: I was assigned this draft to review for IETF last call, but let 
it slip through the cracks. This review servers as both a last call 
and telechat review. Apologies for any inconvenience this might have caused.


Major issues:

-- This draft defines two different procedures for accomplishing the same 
goal. While it describes them as primary and alternative, it is not 
clear to me if an implementation is expected to implement both of them, 
or whether they are intended to interoperate. It would also be helpful to 
have some guidance on when one might choose one over the other.


Minor issues:

-- section 4, 4th paragraph:

ben: When might it make sense to not include the labels? What are the 
consequences of not doing so? (i.e. can you motivate why is this a 
SHOULD and not a MUST?)

-- section 4.1, 3rd paragraph from end (last bullet list entry):

I'm surprised the notification requirement is only a "MAY". Is that per 
RSVP-TE in general, or unique to this scenario?

-- section 4.1, 2nd to last paragraph:

Why only "SHOULD release"? If they don't release state at this time, 
does it cause a problem?

-- section 4.2.1.1, 2nd to last paragraph:

Why only a SHOULD? Does it cause problems if the flag is not set?

-- section 4.2.2.3, case III: 

The "MAY generate" requirement seems to mean that, even if the RECOVERY 
LABEL is present, LSR B may or may not send a PathErr. Is this the 
intent? Is there any negative consequence of not sending PathErr if the 
label is present?

-- section 5, first paragraph:

Do you mean to make a normative requirement that implementations MUST 
support both methods? Are the methods intended to be interoperable? 
(Please excuse my lack of RSVP-TE knowledge--is it a matter of the 
ingress node selecting a method, and downstream nodes just do the 
right thing, or does each node have to understand the selected method?) 
How would an ingress node decide which method to use? (see "major issue" 
above)


Nits/editorial comments:

-- Abstract, first paragraph, first sentence:

I can't parse first part of sentence. Should "? connections are controlled ?" 
be "?connections controlled?"? 

-- Abstract, end of last sentence: Should "...Data plane." be "...Data 
plane connection."?

-- section 1, first paragraph:

s/"? within Management Plane?"/"? within the [or 'a'] Management Plane? " 

-- section 1, third paragraph:

Please expand LSP on first mention.

-- fourth paragraph:

Please expand RSVP-TE on first mention.

-- section 4.1, 2nd paragraph:

ben: What is the antecedent for "it" in "... it supplies the exact path?"

-- 5th paragraph:

Please expand LSR on first mention.

-- section 4.2.1.1 and later:

Figure numbers would be helpful.

-- section 4.2.2.1, 1st paragraph, last sentence:

I didn't find details about PathErr construction in 4.2.1.1 (other than 
a requirement to send it)

-- 2nd paragraph:

I don't see any mention of PathTear in 4.2.1.1.

-- last paragraph:

s/PahTear/PathTear

-- section 4.4, Case I

The passive voice in "?deletion procedure MUST NOT be followed" obscures 
which node(s) you mean to forbid from following the procedure. I 
_think_ you mean that any node in the path MUST NOT?, correct?

-- section 7.1:

Is this intended to recommend IANA choose 25?

-- section 7.2:

Do you mean to recommend a code of 35?

-- section 8:

Last two sentences appear to have missing words.

-- sections 11 and 12

It seems unusual to find Security and IANA considerations after the 
contributors section. I'm not sure if that violates any policy or 
not, but I am afraid some readers may never read all the way to section 11.

-- idnits returns the following:

> > idnits 2.12.00 
> > 
> > tmp/draft-ietf-ccamp-pc-spc-rsvpte-ext-06.txt:
> > 
> >   Checking boilerplate required by RFC 5378 and the IETF Trust (see
> >   http://trustee.ietf.org/license-info):
> >   ----------------------------------------------------------------------------
> > 
> >   == You're using the IETF Trust Provisions' Section 6.b License Notice from
> >      12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
> >      http://trustee.ietf.org/license-info/)
> > 
> > 
> >   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
> >   ----------------------------------------------------------------------------
> > 
> >      No issues found here.
> > 
> >   Checking nits according to http://www.ietf.org/ID-Checklist.html:
> >   ----------------------------------------------------------------------------
> > 
> >   ** There is 1 instance of too long lines in the document, the longest one
> >      being 1 character in excess of 72.
> > 
> > 
> >   Miscellaneous warnings:
> >   ----------------------------------------------------------------------------
> > 
> >   == The document seems to lack a disclaimer for pre-RFC5378 work, but was
> >      first submitted before 10 November 2008.  Should you add the disclaimer?
> >      (See the Legal Provisions document at
> >      http://trustee.ietf.org/license-info for more information.) -- however,
> >      there's a paragraph with a matching beginning. Boilerplate error?
> > 
> > 
> >   Checking references for intended status: Proposed Standard
> >   ----------------------------------------------------------------------------
> > 
> >      (See RFCs 3967 and 4897 for information about using normative references
> >      to lower-maturity documents in RFCs)
> > 
> >   == Missing Reference: 'RFC 3473' is mentioned on line 637, but not defined
> > 
> >   == Unused Reference: 'RFC3471' is defined on line 852, but no explicit
> >      reference was found in the text
> > 
> > 
> >      Summary: 1 error (**), 4 warnings (==), 0 comments (--).
> > 
> >      Run idnits with the --verbose option for more detailed information about
> >      the items above.