I am reviewing 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. Feel free to forward to any appropriate forum.   This I-D defines some extensions to the protocol defined in RFC 5440, and since those extensions do not affect the security sensitivity of the protocol in any significant way, the document appropriately refers to that one for Security Considerations.   That said, the Security Considerations section of RFC 5440 is somewhat dubious. It requires that implementations of this protocol MUST support TCP-MD5 (RFC 2385) as a security mechanism, with recommendations that they implement TCP-AUTH when it becomes available. It notes that TLS and IPsec might be preferable at some point in the future if key management issues can be resolved. TCP-MD5 (and its successor TCP-AUTH/TCP-AO) were developed to solve some specialized problems associated with BGP – in particular, the ability to maintain a TCP connection for an indefinite period (often counted in years) surviving reboots of the endpoints. Its keying is manual, which quickly becomes unworkable as the number of endpoints rises. In response, it is common to use group keys (where the same key is used to protect all of the connections within a realm). TCP-MD5 also provides no confidentiality of data, in spite of the fact that this I-D says the data carried by this protocol may be somewhat sensitive.   This reviewer believes that TLS or IPsec would have been a better choice (and given the current state of the world, TLS would be the better of the two), and that the developers of this protocol should consider supporting one of those in the future. Manual keying could still be used with those protocols, though it would be better to issue certificates to the various endnodes. These certificates need not (and perhaps should not) chain to a commercial root; they could be issued by the same administrators who today configure the shared keys.   But… there is no reason to hold up approval of the updates in this document. Protecting the protocol by authenticating the endpoints and protecting the integrity of the data seems both necessary and sufficient; I don’t see any need to include any other forms of security analysis.   ===== I found the following minor (typo-level) issues:   p4 para 4 line 8: distributed -> distributing p4 para 5 line 6: promote -> promotes p5 para 2 line 10: preemption -> ??? (**I suspect you didn’t mean preemption, but I can’t guess what word you meant) p9 para 3 line 1: regards -> regard p10 para 1 line 7: LSP -> LSPs (**though perhaps some different wording change would be better) p15 section 5.2 line 3: computation -> computations p18 defn MU line 2: all link -> all links p18 defn mU line 2: all link -> all links   There are several places (beginning with section 5.4 defn Type) which read “To be defined by IANA (suggested value = 5)”. Unless there are multiple revisions to this protocol going on in parallel (such that the values assigned might depend on the order in which the documents are advanced), I believe the normal protocol is for an I-D to just specify the new value and repeat it in the IANA considerations section (which this document does). That will minimize work for the RFC editor.