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