Subject: [Ntp] New Version of draft-ietf-ntp-packet-timestamps

From: Tal Mizrahi <[email-masked]>
Date: Sun, 24 Jun 2018 10:35:54 +0300

Hi,

We have uploaded a new version of the draft.

https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-02

We believe this version addresses all the issues raised in the previous
IETF meeting:
- The comment from Yaakov about clarifying the IEEE1588 version in the
PTP-based timestamp format is resolved.
- There were two additional comments that we believe were addressed on the
mailing list:
https://www.ietf.org/mail-archive/web/ntp/current/msg02404.html

Another issue that was discussed in IETF 101 is whether the draft should be
split into two drafts (one describing the timestamp formats, and the other
specifying the control field). Based on the feedback we received, and after
consulting with the WG chairs, it was decided that the draft will not be
split into two drafts. The section that specifies the control field has
been trimmed down, and now specifies the high-level objectives of the
control field. In the near future we will start working on a draft that
will define the detailed specification of the control field.

We believe the current version of the draft is ready for publication, and
would like to ask the chairs to start the WG LC.

Thanks,
Tal, Joachim, Al.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 25 Jun 2018 13:17:53 +0200

> https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-02

Hi Tal,

I've few comments and questions for this draft.

In the description of the 64-bit NTP format, the epoch is specified as
"1 January 1900 at 00:00 UTC". As UTC didn't exist at that time, it
might not be obvious what that means. RFC 5905 has a few sentences
about that. Would it be more clear if it explained that it is actually
the number of seconds since 1 January 1970 + 2208988800?

The description of leap seconds in the NTP format could specify which
seconds are missing in the time scale (i.e. the last second of the day
is ambiguous) and maybe point out that it's not compatible with POSIX
(which requires the first second of the following day to be replayed).

Instead of saying that a format is or is not affected by leap second,
would it be more clear if it said whether it includes or does not
include leap seconds? PTP (usually) includes leap seconds. NTP does
not.

The NTP short format is described as a timestamp format, but is there
any protocol that actually does that? I don't see it in
[I-D.ietf-ippm-initial-registry]. I think it's a fixed-point format
intended for short intervals and other small values, but not for
timestamps.

PTP timestamps are typically used with the PTP epoch and include leap
seconds. However, the PTP specification allows an "arbitrary" time
scale to be used in a PTP domain (signaled by a bit in PTP packets).
To me it would make more sense if the specification of the format was
separated from the epoch and handling of leap seconds. The same
timestamp format can be used differently in different contexts.

-- 
Miroslav Lichvar

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 25 Jun 2018 15:09:41 +0300

Hi Miroslav,

Thanks for reviewing the draft.
We will try to address you comments in the next revision.

>the number of seconds since 1 January 1970 + 2208988800?

Right, we will clarify what we mean by 1900 UTC.

>(which requires the first second of the following day to be replayed).

We will add these notes to the NTP time format.

>include leap seconds? PTP (usually) includes leap seconds. NTP does

After giving this some thought, "includes leap seconds" also seems a bit
ambiguous.
We will think of a way of clarifying this.

>intended for short intervals and other small values, but not for

Right. This format is also used by draft-ietf-sfc-nsh-dc-allocation.
We will look into this and update the text.

>timestamp format can be used differently in different contexts.

We have had quite a bit of discussion about this distinction. Please note
that the timestamp specification (Section 3) make a distinction between the
syntax and the semantics of the timestamp format.
We also had a lot of discussions about the control field(s) (Section 7)
that may affect the timestamp semantics. Your example falls into that
category.
I believe the current draft makes the right distinction between the syntax
and semantics, with Section 7 discussing control fields.

Cheers,
Tal.

---

From: Warner Losh <[email-masked]>
Date: Mon, 25 Jun 2018 09:13:38 -0600

> the number of seconds since 1 January 1970 + 2208988800?

It would be better to state, if you are going this way, to state 1 Jan 1972
+ 2208988800 + 31536000 since all that whacky business with rubber leap
seconds and frequency shifts didn't end until 1972.

> (which requires the first second of the following day to be replayed).

POSIX requires no such thing. In POSIX leap seconds do not exist *AT*ALL*
and so any claim about what POSIX requires is false. Leap second behavior
is 100% undefined. FreeBSD, for example, will replay the last second of the
day to avoid start of day scripts from accidentally running twice.

It is true that the encoding, 23:59:60, when decoded with the POSIX
routines, does decode to the first second of the following day, but that's
a different statement. That's a natural result of the 'do math on fields'
feature of the conversion routines, nothing more. However, since POSIX
specifically excludes the ability to encode a leap second in a time_t,
that's specifically an implementation defined detail. This is the biggest
problem with POSIX.

> include leap seconds? PTP (usually) includes leap seconds. NTP does

It is the number of PPS pulses (or equivalently the number of SI seconds)
since an epoch, with the positive leap seconds subtracted and the negative
leap seconds added.

Warner