Last Call Review of draft-ietf-ntp-packet-timestamps-07

Request Review of draft-ietf-ntp-packet-timestamps
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-02-20
Requested 2020-02-06
Authors Tal Mizrahi, Joachim Fabini, Al Morton
Draft last updated 2020-02-07
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 Russ Housley
State Completed
Review review-ietf-ntp-packet-timestamps-07-genart-lc-housley-2020-02-07
Posted at
Reviewed rev. 07 (document currently at 09)
Review result Almost Ready
Review completed: 2020-02-07


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

Document: draft-ietf-ntp-packet-timestamps-07
Reviewer: Russ Housley
Review Date: 2020-02-07
IETF LC End Date: 2020-02-20
IESG Telechat date: Unknown

Summary: Almost Ready

Major Concerns: None

Minor Concerns:

Abstract: It is too long.  In my opinion, the second paragraph should
be moved to the Introduction.

Section 2.1: Please use:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Section 2.3, paragraph 1: I think it would be better to define timestamp
error without using the phrase "device under test".  If you disagree,
please add a definition for "device under test".

Section 3, Synchronization aspects: The paragraph should also say that
there might not be any synchronization considerations.  For example, an
epoch since the device was powered up does not have any.

Section 9:  Please say "such as Message Authentication Codes (MAC)".
HMAC is one instance of a MAC, and you are not trying to name a specific
algorithm here.

Section 11.2:  RFC 1323 has been obsoleted by RFC 7323.  Is there a
reason that it is better ot reference the older document here?


General: Some places this Internet-Draft refers to itself as "this memo"
and other places if refers to itself as "this document".  Please pick.

Section 1, paragraph 1: Nonces often have a timestamp embedded in them.
For example, TLS 1.2 [RFC5246] defined the nonce as:

         struct {
             uint32 gmt_unix_time;
             opaque random_bytes[28];
         } Random;

So, I think the paragraph should include something about using time to
create an unlikely to repeat value.

Section 3: I do not find the "+" improves readability.

Section 3 says:

      The structure of the timestamp field consists of:

      + Size: The number of bits (or octets) used to represent the
      packet timestamp field.  If the timestamp is comprised of more
      than one field, the size of each field is specified.

Since there is only one item, I suggest:

      Size: The structure of the timestamp field consists of the number
      of bits (or octets) used to represent the packet timestamp field.
      If the timestamp is comprised of more than one field, the size of
      each field is specified.


Should RFC 6019 be included in the table in Section 6?