Guidelines for Defining Packet Timestamps
RFC 8877

Note: This ballot was opened for revision 08 and is now closed.

(Suresh Krishnan) Yes

(Alexey Melnikov) Yes

Comment (2020-03-05 for -08)
Thank you for this document.

Francesca Palombini (see below) pointed out that this document would create DownRef whenever it is referenced, so maybe this document should have been a PS.

* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly * 
* about perceived successes or failures of this experiment.          *

The following comments were provided by Francesca Palombini <>.

Francesca would have balloted *No Objections* on this document. She wrote:

Miscellaneous warnings:

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords -- however, there's a paragraph with
     a matching beginning. Boilerplate error?

     RFC 8174, paragraph 11:
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        and "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.     

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

  Checking references for intended status: Informational

(Deborah Brungard) No Objection

(Alissa Cooper) No Objection

Roman Danyliw No Objection

Benjamin Kaduk No Objection

Comment (2020-03-04 for -08)
Could this go for BCP instead of Informational?  (That would avoid a
need in the future to get it added to the downref registry.)

When we discuss the NTP timestamp formats, we say that "during and
possibly after the occurrence of a leap second, the value of the
timestamp may temporarily be ambiguous, as further discussed in Section
5."  But in Section 5 we discuss the possibility of behavior where
"[t]he clock is slowed down during the leap second and adjacent time
intervals until the new time value catches up."  These statements seem
incompatible unless "adjacent time intervals" occur only after the leap
second, which is not my understanding of how leap-second smearing is
performed in practice.

Section 1.1

   Timestamps are widely used in network protocols for various purposes:
   timestamps are used for logging or reporting the time of an event,
   delay measurement and clock synchronization protocols both make use
   of timestamped messages, and in security protocols a timestamp is
   often used as a value that is unlikely to repeat (nonce).

Some security protocols also use timestamps directly for security
functionality, e.g., using a replay cache for messages within a certain
time window of the past and discarding older ones.  That usage is mostly
unrelated to what is discussed in this document, and I don't really see
a need to mention it in the document, but will mention it here in case
opinions differ.

Section 3

When multiple fields are used (with different units), what needs to be
said about how the two fields are combined and/or any restrctions on the
allowed range of the fields?  (E.g., for the "joke" timestamp format
that has a seconds plus centiseconds representation, are values greater
than or equal to 100 centiseconds forbidden?  Do we envision
applications other than "convert values to a common unit and add them"
for multiple fields, such as explicit fields to convey timestamp
accuracy and/or precision?)

Section 4

   This document defines a set of recommended timestamp formats.
   Defining a relatively small set of recommended formats enables
   significant reuse; for example, a network protocol may reuse the NTP
   or PTP timestamp format, allowing a straightforward integration with
   an NTP or a PTP-based timer.  Moreover, since accurate timestamping
   mechanisms are often implemented in hardware, a new network protocol
   that reuses an existing timestamp format can be quickly deployed
   using existing hardware timestamping capabilities.

This text feels very familiar by this point in the document...

Section 4.2.1

Just to check: we assume by definition that no leap seconds occurred
prior to the creation of UTC when we say that 2272060800 is the number
of seconds between 1 Jan 1900 and 1 Jan 1972, right?

Section 7

I assume the WG considered whether this content could be spun off into a
separate document, e.g., one that defines specific timestamp control
fields, but decided that it is important enough to publish now.

Section 9

Is it in scope to discuss considerations relating to applications that
have an inaccurate sense of the current time, or network packets that
contain timestamps intended to be synchronized to a reference but in
fact are not?  (I see a decent argument that it is not in scope, but
want to check.)

Section 11.2

I assume the self-reference will get removed by the RFC Editor.

(Mirja Kühlewind) No Objection

Comment (2020-03-02 for -08)
Thanks for this well-written document. Was it discussed to publish this document as BCP?

Please also see the TSV-ART review comments (Thanks Ian for the review!)!

(Barry Leiba) No Objection

Comment (2020-03-04 for -08)
I agree with the other comments that this would be a good candidate for BCP.  Section 1.3 really screams “BCP” to me.

Alvaro Retana No Objection

(Adam Roach) No Objection

Éric Vyncke No Objection

Comment (2020-03-02 for -08)
Thank you for the work put into this document. It is indeed useful to have common timestamp formats.

I was about to ballot a DISCUSS on the point in section 1.1 but I am trusting the Security Area Directors for their own reviews.

Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors).

I hope that this helps to improve the document,




-- Section 1.1 --
When writing "security protocols a timestamp is often used as a value that is unlikely to repeat (nonce)", I sincerely believes that this is probably misleading as nonce should probably have entropy and be non-predictable. A timestamp does not have those properties. Again, I am trusting my SEC AD peers on their final words.

-- Section 2.1 --
Is BCP 14 boilerplate required for an informational document ? I have found only one "MUST" in the security section but again this is weird for an informational document.

-- Section 3 --
Should the syntax also include the bit ordering ? I.e., little endian of big endian ? Of course the default if network order but what if it is not ?