[Tsv-art] Tsvart last call review of draft-ietf-ntp-packet-timestamps-08

Ian Swett via Datatracker <noreply@ietf.org> Mon, 02 March 2020 16:47 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 021873A0B19; Mon, 2 Mar 2020 08:47:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ian Swett via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: last-call@ietf.org, draft-ietf-ntp-packet-timestamps.all@ietf.org, ntp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158316762892.27374.16780761185123723332@ietfa.amsl.com>
Reply-To: Ian Swett <ianswett@google.com>
Date: Mon, 02 Mar 2020 08:47:09 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/zswWKK-9wMBUOUyyb6VYRtx0yuo>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-ntp-packet-timestamps-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 16:47:16 -0000

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