Reviewer: Ian Swett Review result: Ready with Nits Overall, this draft looks very good. It uses 'should' non-normatively more often than I'd like. In some cases, I wonder if they should be normative SHOULDs. Section 1.2(Scope) Timestamps are also used in RTP(RFC3550). Based on your document, I think these are out of scope, because they're 'application' timestamps, not network timestamps? I was unclear on this until I read the draft, so if they are out of scope, it would have helped me if you said that application timestamps, such as RTP are out of scope. Section 3, under "Epoch:" Since on power up is an example of a relative timestamp and not the only possible relative timestamp, I'd suggest ", in which the epoch could be the time at which..." The current reading implies that all relative timestamps are due to the start being the power up time, and I don't think that's true. Section 4 I'd change "Specifically, if the network..." to "For example, if the network..." Section 9, Security Considerations The sentence beginning with "Timestamps can be spoofed or modified..." implies that all network timestamps have this property, but you rightly point out later in the paragraph that one can add a MAC to prevent modification. I'd suggest something like "In some cases, timestamps can be..." to avoid the implication that all of them can be spoofed or modified. This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
