Subject: [Gen-art] Gen-ART LC Review of draft-ietf-l3vpn-e2e-rsvp-te-reqts-04

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Oct 2009 17:31:14 -0500

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