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@xxxxxxxxxxx] > Sent: 31 January 2011 22:25 > To: draft-ietf-ccamp-mpls-tp-cp-framework.all@xxxxxxxxxxxxxx; 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf