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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
