Title: review of draft-ietf-mpls-loss-delay-03 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. The abstract for draft-ietf-mpls-tp-loss-delay-profile-03 describes it as "a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices [sic] to meet the specific requirements of MLS-TP." It is a very brief (5 pages, including boilerplate) document intended as an informational RFC. The document that forms the basis for this profile, draft-ietf-mpls-loss-delay-01, is also in progress. The security considerations section of this document refers to the base document cited above. Since this document is a profile of that one, this is a reasonable indirection. (I note that the document under review cites version 1 of that base document, and that version 2 is now current, something that can be addressed later.) I looked at the security considerations section of the base specification. It is two paragraph in length. The first paragraph does a reasonable job of describing the top level security concerns associated with the exchange of performance monitoring messages in a context such as this. (The text would be better if the third concern were identified as "confidentiality.") The second paragraph, however, states:    If reception or alteration of performance-related data by    unauthorized devices is an operational concern, authentication    and/or encryption procedures should be used to ensure message    integrity and confidentiality.  Such procedures are outside the    scope of this document, but have general applicability to OAM    protocols in MPLS networks. First, this paragraph is poorly worded (e.g., the mixed uses of "authentication," "encryption," "integrity," and "confidentiality"). Second, there is concrete reference to any candidate security mechanisms that can provide such services. I am not aware of any IETF standards that might offer such services for MPLS traffic. If there are none, this second paragraph is not adequate; if there are, they should be cited here.