I have 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 with the intent of improving security requirements and considerations in IETF drafts.   Comments not addressed in last call may be included in AD reviews during the IESG review.   Document editors and WG chairs should treat these comments just like any other last call comments.   As far as security is concerned, I see no problems with this document. Tracing back through the list of Security Consideration sections of cited documents in one case leads to a disappointing origin in RFC 2747. The other chain is shorter and more relevant, and it provides greater confidence that this document yields no new security concerns.   This document describes extensions to RSVP to enable creating a bidirectional LSP from two p-t-p unidirectional LSPs.   The security considerations section consists of just two paragraphs. The first cites the security considerations section of RFC 6780 (RSVP Association Objects) as encompassing any security issues that might arise in this context. (The assertion is that this document introduces no new signaling information, and thus no new security concerns.)   The Security Considerations section of 6780 is also two paragraphs in length. That text states that no new security considerations have been introduced, because no new procedures have been defined. Hence it cites the   Security Considerations sections of RFC 4872 and 4873.   RFC 4872 cites RFC 4426 (RFC 4873 cites RFC 4872).   The security considerations section of 4426 is almost a full page. It specifies security services that are required to protect the GMPLS recovery mechanisms defined in that document, but does not point to ANY security mechanisms that should be employed.   RFC 4872 also establishes a few security-relevant requirements for RSVP signaling, and cites RFC 2747 as specifying the required security mechanisms. (4872 also notes that IPsec could be employed for hop-by-hop integrity and authentication, and cites RFC 3473. I note that 3473 is from 2003, and thus refers to IPsec and IKE RFCs that have been obsoleted!)   RFC 2747 specifies crypto authentication mechanisms for RSVP, but dates from 2000. It anticipates that “ … the IETF will define a standard key management protocol” and thus omits specification of such in that document. (A fun walk down memory lane …)     The second paragraph of the Security Considerations section of this I-D notes that additional information is conveyed in the REVERSE_LSP object, but that the information is not fundamentally different from what is carried in a bidirectional LSP message. Thus, the argument is that no fundamentally different information is being transmitted. This paragraph cites RFC 5920 ( Security Framework for MPLS and GMPLS Networks) as relevant. I agree that 5920 seems to be most appropriate RFC in this context.