Residence Time Measurement in MPLS Networks
draft-ietf-mpls-residence-time-15

Thank you for the planned text to update the document to address my Discuss & comment.

I have no objection, but do have some a few minor comments:

Substantive:

-2.1, 4th paragraph from end: Can you offer guidance on what might constitute a reasonably bound wait time?\

-2.1, 2nd paragraph from end: "... MUST NOT do both": What's the scope of that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same message?

Editorial:
- Abstract: The last paragraph is a single, long sentence. Please consider breaking it into simpler sentences.

- 2.1, paragraph 9: "This bit, once it is set by a two-
   step mode device, MUST stay set accordingly": Can that MUST be stated in process terms? That is, <actors>  MUST NOT unset this bit..."

-2.1, paragraph 11:  "Without loss of generality should note
   that handling of Sync event messages..." : I don't follow the sentence; are words missing and/or out of order?
-- "Following outlines handling of PTP Sync event message by the two-step RTM node.": I think there's a missing "the" at the start. It's absence completely changes the meaning of "following outlines"-- as written it seem like the verb is "following", but I think you mean it to be "outlines".
-- I have trouble matching some pronouns to their antecedents in the rest of the paragraph.

I agree with Stephen after reading though Ben's excellent review and the responses. Thanks for incorporating his suggestions.

High level comment:
Maybe extend the security section a bit and describe what can happen in the worse case if the value has been modified to a too high or too low value; and maybe even given some guidance on performing additional checks to figure out if a given value is reasonable for a given path or not.

Questions:
- Can you explain why PTPType, Port ID, and Sequence ID are needed in the PTP Sub-TLV format if those values are already in the PTP packet itself that follows?
- Why is it necessary to define PTP sub-TLV (and have a registry for one value only)? Are you expecting to see more values here? What would those values be?
- Similar to Spencer's question: Why don't you also define a Sub-TLV format for NTP?
- sec 4.3: "RTM (capability) - is a three-bit long bit-map field with values
      defined as follows:
      *  0b001..."
  Maybe I don't understand what a bit-map field is here but these are more then 3 bits...?
- also sec 4.3.: "Value contains variable number of bit-map fields so that overall
      number of bits in the fields equals Length * 8."
  However there is no field 'Value' in the figure... Also the following explanation about future bit-maps is really confusing to me; why don't you just say that the rest as indicated by the length field must be padded with zeros...?
- Should section 4.8 maybe be a subsection of 4.7? This part confused me a bit because the example seems to be generic but the rest is RSVP-TE specific, right? Maybe move the example as a separate section before or after the whole section 4...?

Nits:
- Maybe change to title to: Residence Time Measurement (RTM) in MPLS network
- There are (still) some not spelled out abbreviations (LDP, PW); in turn others are extended twice (e.g. PTP)...
- In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also indicate it as optional in the figure: Sub-TLV (optional)

I'm a bit confused on one point. There's one reference to NTP in the Introduction, everything else is about PTP, but the specification never actually says if this mechanism is intended to be usable for NTP as well. Could that be clearer?

Ben Kaduk's fine secdir review [1] and the resulting
discussion with authors made me very confident that this
one only needed a cursory read from me. Thanks to all for
that!

[1] https://mailarchive.ietf.org/arch/search/?email_list=secdir&gbt=1&index=KaiVCjdJVovCj049ksWXoot6B98