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 (--).
>

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.

s/"statistical assumption"/"statistical assumptions"    (should be  
plural.)

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.

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.

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 ( ... ( ...  
( ... ) ... ) ... )

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.)

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.

paragraph 5:

A comma would be a better choice than parentheses in this context.

paragraph 7:

Why is it okay to omit unconstrained TE LSPs that are provisioned?

Section 3.1, definition of "Value"

Is the encoding of the numeric value well-known for this context, or should this document specify it?

Section 3.2, definition of "Value"

Is the encoding of the numeric value well-known for this context, or should this document specify it?

Section 4 , title:

I'm not sure what the title means. I suggest "Procedures".

paragraph 1:

Is that intended to be a normative SHOULD?

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.

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.

Additionally, I got a 550 Invalid User error for mrm@gblx.net, who is one of the authors. It would be good to get a correct address prior to publication.