Subject: [Gen-art] Gen-ART LC Review of draft-ietf-mpls-number-0-bw-te-lsps-09

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Apr 2008 16:02:43 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Apr 2008 16:16:08 -0500

Additionally, I got a 550 Invalid User error for [email-masked], who is  
one of the authors. It would be good to get a correct address prior to  
publication.

Thanks!

Ben.

> IESG Telechat date: (if known)

[...]