Last Call Review of draft-ietf-rtgwg-cl-requirement-13
review-ietf-rtgwg-cl-requirement-13-opsdir-lc-tsou-2013-12-10-00

Dear all,

I have reviewed this document as part of the operations directorate's

ongoing effort to review all IETF documents being processed by the

IESG.  These comments were written primarily for the benefit of the

operations area directors.  Document editors and WG chairs should treat

these comments just like any other last call comments.

In general this seems to be excellently written. The management requirements
seem to be well covered. A couple of substantive remarks:

1. One question regarding a non-requirement that is expressed in mandatory
language. The paragraph following FR#14 in Section 3.4 reads:

"A client LSP which is bound to a specific component link SHOULD NOT

exceed the capacity of a single component link."

Is this a requirement on implementations to check for such a condition? In that
case, maybe it could be expressed as an FR. In the opposite direction, is it a
requirement on implementations at all? If not, perhaps it doesn't belong here.

2. Another point: the Definitions section defines a flow as a sequence of
packets that should be transferred in order on one link of a multipath. Is
FR#15 intended to solidify that "should" into a MUST in some cases, or is there
an implicit confusion regarding
 the definition of "flow"?

There are a few nits:

Table of Contents: there is an apparent tab in the title of Section 3.2. Check
to see if there is a character other than blank preceding the last word of the
title.

Throughout: LSP is not a well-known abbreviation according to the RFC Editor's
list at

http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

, hence must be spelled
 out on first use. Similarly for LSR where it is used in the Definitions
 section.

Section 3.2, last para, second-last sentence: superfluous "it":

OLD

"... is that it if used in routing decisions ..."

NEW

"... is that if used in routing decisions ..."

Section 3.4, first para: "PTP" does not appear in the RFC Editor's list of
abbreviations, hence must be spelled out. "NTP" is OK (marked as well-known).

3.4, second para: spell out TTL

3.4, last para, second sentence:

"Without and entirely new..." -> "Without an entirely new ..."

"... such an bidirectional ..." -> "... such a bidirectional ..."

GR#2: spell out TE

GR#3: spell out RSVP-TE. RSVP itself is considered to be a well-known
abbreviation, as is LDP.

Thank you,

Tina