This document describes how to make an MPLS-TP path one one party (party A) appear to be an MPLS-TP link of another (party B), in other words, tunneling party B's MPLS-TP information over party A's -provided path. As noted in the security considerations section, there are no new security issues raised by using this already-existing mechanism for this purpose. One comment: Rao Cherukuri's email address seems to be missing from "authors' addresses". A couple of questions, really...it looks like the term "Transport" is used in the MPLS/ITU context to mean more like layer 3, rather than end-to-end layer 4 (like TCP). Although this always seemed a much more natural use of the term "transport" (since layer 3 and layer 2 really do transport things and layer 4 doesn't), why is it is called "TP" here? And in the security considerations section it mentions the problem of static configuration having the possibility of a forwarding loop. Again just a comment -- admittedly a packet can go round the loop a few times before the TTL expires, but given that there is a TTL, it seems like a looping MPLS path might not be too bad. Especially if part of the static configuration would be the TTL to initiate packets on, for a particular MPLS path. But as for the document being reviewed -- no security issues. Radia