I previously reviewed the -12 (https://www.ietf.org/mail-archive/web/secdir/current/msg07110.html); the -14 seems much improved. On this re-read, I have a better sense of how the various TLVs and sub-TLVs fit together to achieve the goal of having the RTM-capable nodes identify each other and collaborate to account for residence time when processing timing packets. I have no security concerns with the document, as the updated security considerations address the concerns previously raised. However, there are a couple of issues that should probably block publication (but ought to be easy to resolve): Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7 bits, 'Length' 8, 'I' 1, and 'Reserved' 15. Presumably Type is intended to be the full 8 bits, given the assigned values in the registry. On page 16, second paragraph: The ingress node MAY inspect the I bit flag received in each RTM_SET TLV contained in the LSP_ATTRIBUTES object of a received Resv message. Presence of the RTM_SET TLV with I bit field set to 1 indicates that some RTM nodes along the LSP could be included in the calculation of the residence time. An ingress node MAY choose to resignal the LSP to include all RTM nodes or simply notify the user via a management interface. Is that supposed to be "included" or "excluded"? My reading of the previous paragraph was that the I bit would be set when a node failed to compute the next RTM-capable node along the path, and of course, we expect normal operation to include the residence time for all RTM-capable nodes, so signalling potential inclusion is odd. I'll close off this review by noting that sections 4.3 through 4.6 seem to all talk about how to use other protocols to indicate that RTM may be used and could perhaps be grouped into an intermediate subsection, wondering whether the "Type" and "Length" fields in Figure 2 are the same octets of the packet as in Figure 1, and repeating my as-yet unfulfilled intention to send further minor editorial patches to the authors. -Ben