Document: draft-ietf-l3vpn-e2e-rsvp-te-reqts-04
Reviewer: Ben Campbell
Review Date:  20-Oct-2009
IETF LC End Date: 20-Oct-2009
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as an informational RFC. I have 
a few minor and a number of editorial comments that should be addressed prior 
to publication.

*** Major issues:

None

*** Minor issues:

-- section 3, paragraph 3, ""However, if a C-
   RSVP signaling is to send within VPN, the service provider network
   will face scalability issues."

Can you elaborate?

-- Section 6.4:

Last sentence should be something to the effect that "The solution SHOULD 
allow customers to receive?", right?  Otherwise it looks like normative 
requirements on customers.

-- Section 7.1, last paragraph:

Is this acceptable given the explicit requirement not to divulge 
topology information mentioned in the security considerations section?

-- Section 7.2:

 How would you judge compliance with this requirement?



*** Nits/editorial comments:

-- The draft has a bad case of acronym soup. Please make an effort to 
expand acronyms on first mention, unless they are generally well known to 
the community. (And by community, I mean the IETF at large, not just the 
routing area). See 
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt for guidance.

-- The draft has numerous grammar errors. Please proofread it again. 
In particular, watch for singular/plural mismatches, missing articles before 
singular nouns, etc. Also, a spell check is in order.

-- section 1, paragraph 1:
Please define or describe "triple play services", or provide a reference.

-- Section 4.2, last paragraph:

 s/overide/override
s/premption/preemption

-- Section 5.3

s/enviroment/environment
Also, don't use "/" as a conjunction--write out the words.

-- Section 5.11:

Is there a reference for "make-before-break"? Otherwise, please elaborate.

-- Section 6.1:

Do you really mean ingress/egress? I would assume admissions control applies 
to ingress.

-- Section 6.2:
The second sentence doesn't parse. Are there missing or extra words?

-- Section 6.3:

I don't follow the second sentence. Is the third sentence a requirement that 
the solution support local policies for this?

-- Section 7.4, first paragraph, first sentence:

Is that a normative SHOULD?

-- Section 7.4, first paragraph:

I think you mean the solution MUST address scalability for the following 
situations, right?

-- Section 7.6, first paragraph:

You mean to say the solution MUST address manageability consideration, right?

-- same section, "MIB module for C-RSVP paths and C-TE LSPs MUST collect per 
a vrf   instance."

I can't parse that sentence.

-- same section, "If a CE is managed by service providers, MIB information for 
C-RSVP   paths and C-TE LSPs from the CE MUST be collected per a customer."

I don't understand. Who MUST collect? Do you mean to say the solution MUST 
allow collection on a per customer basis?

-- same section, 2nd to last paragraph, "Any diagnostic tool   MUST be 
capable of detecting failures of the control and data plane for C-TE 
LSPs over a VRF instance."

Do you intend to put requirements on the diagnostic tools themselves? Or say "the solution MUST allow?"

-- Section 8, numbered list:

 The list is inconsistent in using full sentences or sentence fragments.

-- same section, 4th paragraph: "If the CE is an untrusted router for 
service providers..."

Do you mean "...a router that is not trusted by the service provider   ". 
(Same pattern repeats in paragraph 5).