Last Call Review of draft-ietf-ntp-packet-timestamps-08
review-ietf-ntp-packet-timestamps-08-tsvart-lc-swett-2020-03-02-00

Request Review of draft-ietf-ntp-packet-timestamps
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2020-02-20
Requested 2020-02-06
Authors Tal Mizrahi, Joachim Fabini, Al Morton
Draft last updated 2020-03-02
Completed reviews Genart Last Call review of -07 by Russ Housley (diff)
Tsvart Last Call review of -08 by Ian Swett (diff)
Secdir Last Call review of -07 by Liang Xia (diff)
Assignment Reviewer Ian Swett
State Completed
Review review-ietf-ntp-packet-timestamps-08-tsvart-lc-swett-2020-03-02
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/zswWKK-9wMBUOUyyb6VYRtx0yuo
Reviewed rev. 08 (document currently at 09)
Review result Ready with Nits
Review completed: 2020-03-02

Review
review-ietf-ntp-packet-timestamps-08-tsvart-lc-swett-2020-03-02

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@ietf.org if you reply to or forward this review.