RE: Gen-ART LC Review of draft-ietf-ccamp-mpls-tp-cp-framework-05

[Adrian Farrel <[e-mail]>]

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:[e-mail]]
> Sent: 31 January 2011 22:25
> To: [e-mail]; 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?)=