Skip to main content

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 revision 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
I-D 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
Request Last Call review on draft-ietf-ntp-packet-timestamps by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/zswWKK-9wMBUOUyyb6VYRtx0yuo
Reviewed revision 08 (document currently at 09)
Result Ready w/nits
Completed 2020-03-02
review-ietf-ntp-packet-timestamps-08-tsvart-lc-swett-2020-03-02-00
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.