Subject: [Ntp] I-D Action: draft-ietf-ntp-packet-timestamps-08.txt

From: [email-masked]
Date: Mon, 24 Feb 2020 05:39:45 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

        Title           : Guidelines for Defining Packet Timestamps
        Authors         : Tal Mizrahi
                          Joachim Fabini
                          Al Morton
	Filename        : draft-ietf-ntp-packet-timestamps-08.txt
	Pages           : 21
	Date            : 2020-02-24

Abstract:
   Various network protocols make use of binary-encoded timestamps that
   are incorporated in the protocol packet format, referred to as packet
   timestamps for short.  This document specifies guidelines for
   defining packet timestamp formats in networking protocols at various
   layers.  It also presents three recommended timestamp formats.  The
   target audience of this document includes network protocol designers.
   It is expected that a new network protocol that requires a packet
   timestamp will, in most cases, use one of the recommended timestamp
   formats.  If none of the recommended formats fits the protocol
   requirements, the new protocol specification should specify the
   format of the packet timestamp according to the guidelines in this
   document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-08
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-packet-timestamps-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-packet-timestamps-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Doug Arnold <[email-masked]>
Date: Tue, 25 Feb 2020 20:55:49 +0000

This is a useful informative document.

One comment:  In the discussion of PTP timestamps, it might be worth talking about the correctionField.  This field is intended to be used to make various types of corrections to the PTP timestamps, including the ability to add sub ns resolution.

Doug

________________________________
From: ntp <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Monday, February 24, 2020 5:39 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Ntp] I-D Action: draft-ietf-ntp-packet-timestamps-08.txt

Abstract:

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 26 Feb 2020 08:41:06 +0100

> https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/

One thing I'd like to be considered is error accounting. In some
applications exchanging a timestamp alone is not enough. It may also
be important to estimate the error in the timestamp. An example is
NTP, which has the root dispersion and delay. Some recommendations for
representing this data might be helpful.

Would that make sense?

-- 
Miroslav Lichvar

---

From: Joachim Fabini <[email-masked]>
Date: Wed, 26 Feb 2020 09:32:58 +0100

> representing this data might be helpful.

Yes, it does make sense (my favourite example is the PMU_TQ field
defined by IEEE C37.118.2-2011, table 7). However, same opinion as
replied to Doug: it fits much better into the separate control field
draft. And yes, the time quality field was one of the main reasons why
we (the authors of the timestamp draft) decided to go for a separate
control field draft.

Short history: we had an all-in-one document but concluded that it's
worthwhile to split it into two. The timestamp draft focuses on the
common case: a default timestamp format, syntax, and basic semantics
that many protocols will be happy with. The timestamp control field
draft defines an optional control field that may augment the default
timestamp: timestamp attributes, options, extended semantics (correction
fields, e.g., PTP or leap second correction may go there). We assume the
control field to be required primarily by protocols that depend on
accurate synchronized time (timesync, critical infrastructures, etc.).

Does this make sense? Imo your and Doug's comment emphasize the
importance of pushing forward the control field draft.

thanks
Joachim

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 26 Feb 2020 10:31:13 +0100

> worthwhile to split it into two. The timestamp draft focuses on the
...

> importance of pushing forward the control field draft.

I think it does if the timestamp document will be useful on its own.
I now recall some of discussions around this split and I probably
don't have anything new to add there.

Thanks,

-- 
Miroslav Lichvar