I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.   These comments were written primarily for the benefit of the security area directors.   Document editors and WG chairs should treat these comments just like any other last call comments.   An overall comment: There are numerous (minor) English errors throughout the document, which I hope will be addressed through the RFC Editor process.   The abstract says that the document describes LDP DoD (downstream on demand) use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. It also describes a new, optional TLV type in the LDP Label Request message. The intent of creating the new type is to enable “fast-up” convergence.   Section 2 of the document is devoted to a description of reference access topologies that will make use of this new MPLS feature. These topologies are divided into two classes: ones that can be supported via static routes and ones that require use of a dedicated IGP, e.g., ISIS, OSPF (v2 or v3), and   RIP (v2 or ng), by the access network.   Section 3 describes use cases for LDP DoD. It too distinguishes between topologies that use static routing vs. an IGP, and examines various types of failures that may affect the LDP DoD nodes. This section includes a lot of normative text, yet almost all instances of the words “must” and “should” are lowercase. The authors should revisit this section to determine if there need to be more MUSTs and SHOULDs.   Section 4 describes the label request procedure. It too contains normative text, yet almost all instances of “must” and “should” are lowercase. As with Section 3, the authors should revisit this section to determine if there need to be more MUSTs and SHOULDs.   Section 5 describes the LDP extension to enable “Fast-Up” convergence. In this very brief section the authors seem to have done a better job of using uppercase terms in normative text.   Section 7 addresses Security Considerations. It cites RFC 5920, the Security Framework for MPLS and GMPLS as the primary reference applicable to security concerns that arise in the MPLS DoD context. RFC 5920 devotes several pages to a discussion of service provider and inter-provider security topics, so it seems natural to cite it here. (It too suffers from a tendency to use the words “must,” “should,” and “may” only in lowercase, despite the apparent normative nature of the comments being made.) Sections 9.1 and 9.2 are odd parts of 5920; the former enumerates potential attacks, and the latter enumerates “deference techniques” without bothering to establish the mapping between the two!   This I-D also cites the Security Consideration section of the MPLS LDP specification (RFC 5036), noting a need for message authenticity and integrity, and for protection against spoofing and DoS attacks. RFC 5036 contains a more conventional Security Considerations section, which seems appropriate to cite here.   In addition to the references to prior RFCs, this section analyzes several security contexts:, in terms of tampering with packet flow direction, data and control plane security, and network node security. The discussion of attacks on packet flow direction seems fairly good, except for the ABR LSR network side case, for which the offered advice is vague. The data place security discussion seems to be a set of suggestions, but with a mix of normative and informative terms; Section 7.2 definitely needs work.   The discussion of control plane security in Section 7.3 is shorter, but not much better. It suggests that the reader be familiar with a KARP I-D ( I-D.ietf-karp-routing-tcp-analysis. This recommendation is not a precise recommendation and thus ought to be reconsidered. The text here also suggests use of TCP/MD5, recommending TCP/AO only if the former is not considered good enough. RFC 5925 (TCP-AO) obsoletes RFC 2385 (use of TCP/MD5 in BGP). This calls into question whether it is appropriate to recommend use of TCP/MD5 at all. The subsection ends with two suggestions: employ better authentication in access locations with lower physical security, and use “stricter network protection mechanism.” The former advice seems good, but the latter is too amorphous to be of much use.   The final subsection in Security Considerations (7.4) discusses additional precautions an operator might employ for nodes that are considered to be at risk due to degraded physical security. Addressing this concern seems reasonable, but the advice is pretty generic, and the wording here is especially poor.