Document: draft-ietf-mpls-number-0-bw-te-lsps-09 Reviewer: Ben Campbell Review Date: 22 August 2008 IESG Telechat date: 28 August 2008 Summary: This document is almost ready for publication as a proposed standard. There are some nits that should be considered prior to publication. Major issues: No major issues Minor issues: I performed a Gen-ART last call review on version 09 of this document, and had a few comments (mostly editorial, and all minor ) which I have included below. With the exception of the partial correction of idnits related comments, these comments still apply. > Document: draft-ietf-mpls-number-0-bw-te-lsps-09 > Reviewer: Ben Campbell > Review Date: 2008-04-18 > IETF LC End Date: 2008-04-25 > IESG Telechat date: (if known) > > Summary: > > This draft is almost ready for publication as a proposed standard, but > there are nits that should be considered prior to publication. > > Comments: > > --General Comment: > > There is a general overuse of parentheses that I personally found > disruptive to the flow of reading. In several cases, commas would > have been more appropriate. The RFC editors are likely to fix these, > but it is good to save them the work. And of course, they might fix > them in a different manner than you might choose. > > -- Specific Comments: > > IDNITS complains about the following: > >> (See RFCs 3967 and 4897 for information about using normative >> references >> to lower-maturity documents in RFCs) >> >> == Outdated reference: A later version (-11) exists of >> draft-ietf-ospf-ospfv3-traffic-09 >> >> -- Possible downref: Normative reference to a draft: ref. >> 'I-D.ietf-ospf-ospfv3-traffic' (No intended status found in >> state file >> of draft-ietf-ospf-ospfv3-traffic) >> >> ** Downref: Normative reference to an Informational RFC: RFC 3784 >> >> >> Summary: 1 error (**), 1 warning (==), 1 comment (--). >> > All fixed except the downref for RFC 3784 > Abstract: > > Please expand TLV and IS-IS on first use. Expanding OSPF would not > hurt, but it is probably well-known enough not to require expansion. No change > > > s/"statistical assumption"/"statistical assumptions" (should be > plural.) No change > > > Requirements Language: > > It's a bit odd to see this prior to the Table of Contents. I usually > see it in the terminology section. I don't know if it matters. No change > > > Section 1: > > Most of the terms are just acronym expansions. It might be nice to put > in short definitions, unless all of the terms are sufficiently well- > known not to need definitions. No change relevant to comment > > > Section 2, paragraph 1: > > I find the heavy use of parentheses to detract from the flow of the > paragraph. Also, when nesting parentheses, please use other symbols. > For example ( ... [ ... { ... } ... ] ... ) instead of ( ... ( ... > ( ... ) ... ) ... ) No change > > > paragraph 2: > > s/"other metric"/"other metrics" (should be plural.) > > "Unfortunately, > for instance in the presence of ECMPs (Equal Cost Multi-Paths) in > symmetrical networks when unconstrained TE LSPs are used, such > metrics (e.g. path cost, number of hops, ...) are usually > ineffective > and may lead to poorly load balanced traffic." > > I found this sentence hard to follow. Can it be simplified? > > paragraph 3: > > s/"statistical assumption"/"statistical assumptions" (should be > plural.) No change > > > Also, can you offer a sentence or two explaining what you mean by > "statistical assumptions"? I think I know what you mean, but I don't > think it will be obvious to all readers. > No relevant change > paragraph 5: > > A comma would be a better choice than parentheses in this context. No change > > > paragraph 7: > > Why is it okay to omit unconstrained TE LSPs that are provisioned? No change > > > Section 3.1, definition of "Value" > > Is the encoding of the numeric value well-known for this context, or > should this document specify it? > No change > Section 3.2, definition of "Value" > > Is the encoding of the numeric value well-known for this context, or > should this document specify it? No change > > > Section 4 , title: > > I'm not sure what the title means. I suggest "Procedures". No change > > > paragraph 1: > > Is that intended to be a normative SHOULD? No change > > > Section 5: > > The text said the type numbers were to be assigned by IANA, with 23 > being a suggested value. That is not clear in the IANA considerations. No change, but after rereading I think it is okay > > > Section 6: > > Can the information carried in this new parameter ever be sensitive, > or useful to an attacker? I'm not saying it is, but it might be useful > to mention this one way or another in the security considerations. No change