Subject: [Last-Call] Tsvart last call review of draft-ietf-ntp-packet-timestamps-08

From: Ian Swett via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 08:47:09 -0800

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
[email-masked] if you reply to or forward this review.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 3 Mar 2020 08:05:15 +0200

Hi Ian,

Thanks for the thorough review.

Please see some comments inline.

> often than I'd like.  In some cases, I wonder if they should be normative

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.

> of scope, it would have helped me if you said that application timestamps, such

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).

> due to the start being the power up time, and I don't think that's true.

Agreed.

> I'd change "Specifically, if the network..." to "For example, if the network..."

Agreed.

> that all of them can be spoofed or modified.

Agreed.

Cheers,
Tal.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 03 Mar 2020 09:11:44 +0100

>>> Tal Mizrahi <[email-masked]> schrieb am 03.03.2020 um 07:05 in
Nachricht
<11168_1583215605_5E5DF3F5_11168_1246_1_CABUE3X=nhuzy1UMEFr1tuJNw9hY_ewYHqoX4fCq
[email-masked]>:

Hi!

I found another little issue while wondering what the document says about "precision":
In "5. Synchronization Aspects" the text claims "Further considerations may be discussed in this section, such as the required timestamp accuracy and precision". However "precision" is not mentioned there.

Basically I feel the definitions given there for precision and accuracy are quite vague.

Personally I feel the concept of precision (as opposed to resolution) should be handled.
Unfortunately POSIXC clock_getres() seems to return the precision for example:

       The  function  clock_getres()  finds  the resolution (precision) of the
       specified clock clk_id, and, if res  is  non-NULL,  stores  it  in  the
       struct timespec pointed to by res.  The resolution of clocks depends on
       the implementation and cannot be configured by  a  particular  process.
       If  the  time value pointed to by the argument tp of clock_settime() is
       not a multiple of res, then it is truncated to a multiple of res.

Regards,
Ulrich