Thanks for the review and these minor points.
Russ, I'm going to capture Ben's review in a Comment attached to my Yes ballot,
and the authors can come back and pick them up after the IESG review complete.
Cheers,
Adrian
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Sent: 31 January 2011 22:25
To:
draft-ietf-ccamp-mpls-tp-cp-framework(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
General Area
Review Team
Cc: The IETF
Subject: Gen-ART LC Review of draft-ietf-ccamp-mpls-tp-cp-framework-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-ietf-ccamp-mpls-tp-cp-framework-05
Reviewer: Ben Campbell
Review Date: 2010-01-31
IETF LC End Date: 2010-01-31
IESG Telechat date: (if known)
Summary:
This draft is effectively ready for publication as an informational RFC. I
have some
minor comments, nits. and editorial comments that may be worth considering
prior to final publication.
Major issues:
None
Minor issues:
-- Section 2 (and subsections)
This section appears to be made up almost entirely of restatements of
requirements that are normatively stated elsewhere. That takes up about 16
pages. Is that really necessary, other than to say which requirements apply to
the
control plane? You could do that by merely calling out the numbers of the
requirements that apply from each document, and making notes when more
explanation is needed. Since you explicitly state that the source documents
are
authoritative, then a careful reader will need to read those documents anyway.
OTOH, a not-so-careful reader may not read the source documents, and
therefore be misinformed if this document introduces any discrepancies.
-- Security Considerations:
Are you willing to assert that no new security considerations are introduced
by
the existing mechanism being used in this new context?
Nits/editorial comments:
-- IDNits returns errors and warnings. Please check.
-- The document lists 5 editors on the front page, and 8 authors in the author
section. That's a bit on the high side. I have no opinion whether that is
reasonable
for this draft--I just call it out so others can decide.
-- Please number the tables.
-- The document makes inconsistent use of references. For example, you jump
between the forms of "... as defined in document[xxx]", "... as defined in
document, see [xxx]", and "as defined in [xxx]". More consistency would make
for easier reading. I personally prefer the first form, and find the second
form
disruptive to the flow of reading.
-- Section 1, paragraph 1: "(MPLS-TP) is being defined"
Be careful with time-sensitive statements such as this. An RFC lives forever,
and
this statement may be nonsensical to readers in e future. At least qualify it
with
something like "at the time of this writing..."
-- Section 1, paragraph 2: "as defined by the ITU-T"
Reference?
-- Section 1.2, numbered list:
This is really just normal information, not a sequence. I suggest paragraph
form,
or a bullet list if you really need a list format.
Please put space between the list entries. A long list like this is difficult
to read
without some white space.
Please expand acronyms on first use. There are a number of unexpanded
acronyms in this section.
-- section 2, first paragraph: "The requirements are summarized in this
section,
but do not replace those documents. If there are differences between this
section and those documents, those documents shall be considered
authoritative."
I assume that makes this entire section non-normative, even though it uses
terms like "must" (albeit non-capitalized). It might be good to say that
explicitly,
as readers may not notice the lack of capitals.
-- section 2.1, req 38:
Do you expect to keep "requirement removed" in the final RFC?
-- ..., req 39:
Which documents are you treating as authoritative for the purpose of this
document, the ITU or IETF documents?
-- req 52:
The referenced requirement says it MUST be possible to require 100% of traffic
on the protected path. "Up to 100%" is not the same thing
-- req 95:
Is that a requirement, or an observation?
-- req 100:
Is that a requirement, or an observation?
-- req 101:
Is that a requirement, or an observation?
-- section 4.1.1: "Out-of-band, in-fiber"
You are talking about any scenario using the same physical network, right? Is
the
concept limited to fiber in any way?
-- section 4.1.1, last paragraph: "Some expect the G-ACh to be used
extensively..."
Who expects it? Can you say something more concrete?
-- 4.1.5, 1st paragraph: "... it is deprecated, and must not be used for
MPLS-TP."
Do you mean that to be normative?
-- 4.1.9, last paragraph: "Recovery for MPLS-TP LSPs as discussed in
[TP-SURVIVE],
is signaled..."
Missing comma before "as"
-- 4.2.1.1, list:
Please use vertical white space between list entries
-- 4.2.1.2
There are lots of statements of the form "must be possible". Do you mean
anything in this section to be normative?
-- 4.4.1, last paragraph: "This work will serve as the foundation..."
The referenced work, or this draft? (Similar question for 4.4.5)
Also, there's an odd mid-sentence paragraph break here in the PDF version.
-- 4.4.5
This whole paragraph is very time sensitive, and asserts a number of things
that
may no longer be true at some point in the future.
-- 5.3, 2nd paragraph: "See the table in the section above"
Please give a section or table number cross reference.
-- 5.3.2, third paragraph: "it may be required that bidirectional traffic
follows
congruent paths."
"May be required" is pretty vague. Are you talking about requirements on the
protocol as listed in this document, or something else? (who may require it?)=
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf