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

Request Review of draft-ietf-rtgwg-cl-requirement
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2013-12-09
Requested 2013-11-28
Other Reviews Genart Last Call review of -10 by Francis Dupont (diff)
Genart Last Call review of -13 by Francis Dupont (diff)
Genart Telechat review of -15 by Francis Dupont (diff)
Secdir Last Call review of -10 by Taylor Yu (diff)
Secdir Last Call review of -13 by Taylor Yu (diff)
Review State Completed
Reviewer Tina Tsou
Review review-ietf-rtgwg-cl-requirement-13-opsdir-lc-tsou-2013-12-10
Posted at http://www.ietf.org/mail-archive/web/ops-dir/current/msg00036.html
Reviewed rev. 13 (document currently at 16)
Review result Has Nits
Draft last updated 2013-12-10
Review completed: 2013-12-10

Review
review-ietf-rtgwg-cl-requirement-13-opsdir-lc-tsou-2013-12-10















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