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 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. This document states many requirements on properties of proposed solutions, but it seems that none of these requirements is a security requirement. If nodes need to send new information that existing routing or signaling protocols do not currently send, what level of protection does that information require? In the Security Considerations section, I'm not sure what the intent is in using the phrasing "man-in-the-middle confidentiality breach". I generally consider "man-in-the-middle" to mean an active attacker (one that can receive, suppress, modify, and transmit arbitrary data); this type of attacker primarily has consequences for integrity. (An active attacker could also compromise the confidentiality of a channel that is secure against passive attackers). A passive attack is often sufficient to compromise confidentiality, especially if a protocol sends information in the clear. What scope of compromise does "provider breach" designate? Editorial: This document uses many acronyms without expanding them -- almost all of them, from what I can see. Some of the more prominent ones include DSCP, LDP, LSP, PW, RSVP-TE. Arguably terms such as MPLS, VLAN, and VPN count as well-known acronyms in the IETF community.