Hi Ian, Thanks for the thorough review. Please see some comments inline. On Mon, Mar 2, 2020 at 6:47 PM Ian Swett via Datatracker <noreply@xxxxxxxx> wrote: > > 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. The draft only uses two instances of (uppercase) normative requirement language words, one in Section 3 (which defines the timestamp template) and the other in Section 9 (Security Considerations). This is intentional, since these are exactly the requirements that the reader is expected to comply to when defining a timestamp. > > 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. Right, timestamps are used in RFC 3550, and actually this is already mentioned in Section 6 of the draft (RFC 3550 has actually two type of timestamps, the "NTP" timestamp, and the "RTP" timestamp). > > 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. > Agreed. > Section 4 > > I'd change "Specifically, if the network..." to "For example, if the network..." Agreed. > > 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. > Agreed. Cheers, Tal. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
