Hi,
I reflected your comments and just submitted a new version(-05).
Thanks,
Kenji
--
Kenji Kumaki, Ph.D. <ke-kumaki(_at_)kddi(_dot_)com>
IP Network Department
KDDI Corporation
<C31006DE-2C8D-4116-88ED-6464B56F0532(_at_)estacado(_dot_)net> の、
"Gen-ART LC Review of draft-ietf-l3vpn-e2e-rsvp-te-reqts-04"
において、
"Ben Campbell <ben(_at_)estacado(_dot_)net>"さんは書きました：
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).
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf