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

From: JP Vasseur <[email-masked]>
Date: Mon, 01 Sep 2008 13:01:30 +0200

Hi Ben,

Thanks for the Gen-art review, sorry if I missed it.

http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-12.t
xt

Comments in line,

On 8/23/08 12:24 AM, "Ben Campbell" <[email-masked]> wrote:

> 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 wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> 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.
> 
> Thanks!
> 
> Ben.
> 
> 
> 
> Begin forwarded message:
> 
>> From: Ben Campbell <[email-masked]>
>> Date: April 18, 2008 4:02:43 PM CDT
>> To: General Area Review Team <[email-masked]>
>> Cc: [email-masked], [email-masked], [email-masked],
>> [email-masked]
>> , [email-masked], [email-masked], [email-masked]
>> Subject: [Gen-art] Gen-ART LC Review of draft-ietf-mpls-number-0-bw-
>> te-lsps-09
>> 
>> 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 (--).
>>> 
>> 
> 
> All fixed except the downref for RFC 3784

Fixed.

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

Done, although these are very well-known terms.

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

Fixed

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

Usual template.

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

They are very well-known terms.

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

I'll leave it to the RFC editor. I personally find that using [] may be
confusing (used for reference).

> 
>> 
>> 
>> paragraph 2:
>> 
>> s/"other metric"/"other metrics"  (should be plural.)
>> 

Fixed, thanks.

>> "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?
>> 

OK I changed the wording for:

" Unfortunately, metrics such as the path cost or the number of hops may be
ineffective in various circumstances: for example, in the case of a
symmetrical network with ECMPs (Equal Cost Multi-Paths), if the network
operator uses unconstrained TE LSP, this may lead to a poorly load balanced
traffic: indeed, several paths between a source and a destination of a TE
LSP may exist that have the same cost and the reservable amount of bandwidth
along each path cannot be used as a tie-breaker. "

>> paragraph 3:
>> 
>> s/"statistical assumption"/"statistical assumptions"    (should be
>> plural.)
> 
> No change

Fixed.

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

I would prefer to leave it unchanged since this may lead to confusion.
Fairly well-known.

> 
> 
>> paragraph 5:
>> 
>> A comma would be a better choice than parentheses in this context.
> 
> No change

Fixed

> 
>> 
>> 
>> paragraph 7:
>> 
>> Why is it okay to omit unconstrained TE LSPs that are provisioned?
> 
> No change

Fairly obvious for the reader skilled in the art.

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

It is well-known, simply the number of unconstrained TE LSP.

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

It is well-known, simply the number of unconstrained TE LSP.

> 
>> 
>> 
>> Section 4 , title:
>> 
>> I'm not sure what the title means. I suggest "Procedures".
> 
> No change

"Elements of procedure" is quite commonly used in this context.

> 
>> 
>> 
>> paragraph 1:
>> 
>> Is that intended to be a normative SHOULD?
> 
> No change

Good catch ! Thanks.

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

OK

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

The text says " The function described in this document does not create any
new security issues for the OSPF and the IS-IS protocols." Furthermore, text
had been updated.

Many Thanks.

JP.

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

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 2 Sep 2008 14:05:48 -0500

This addresses all of my comments except for the following two (which  
are really two instances of the same comment):

> It is well-known, simply the number of unconstrained TE LSP.

For each of these, my question was more to the encoding of the value,  
rather than its meaning. The definition is a 2 octet number. Is that  
binary? digit characters? Something else? Perhaps the underlying  
protocol already defines the encoding for "number", in which case it  
is fine as is.

Thanks!

Ben.