Re: [Ntp] Antw: [EXT] Re: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

[Warner Losh <[e-mail]>]

On Tue, Oct 19, 2021 at 9:18 AM Danny Mayer <[e-mail]> wrote:

>
> On 10/19/21 4:01 AM, Ulrich Windl wrote:
> >
> > Same for UTC vs TAI.
> > I thing the TAI offset (whole seconds) should be part of every NTPv5
> timing packet. So we can keep the old timestamp format while providing TAI.
> > Maybe NTPv6 will demand that TAI should be the new time base. Still we
> would need the offset to provide UTC and similar.
> >
> My proposal for an additional field includes the total number of
> leapseconds added to TAI. You can then use this number to calculate the
> TAI time from the UTC timestamps sent. A zero value for the count would
> indicate the server doesn't know.
>

Is that field signed or unsigned?  How large is it?

Personally, I'd make it a signed 16 bits and have 0x8000 indicating unknown.
We believe today it will always be a positive number that only ever
increases.
However, recent rotation data says that weird short term things can happen
even if we know the long term trend is always increasing and it would be a
cheap way to hedge bets.

But even an 8 bit unsigned field with 0 meaning unknown is a huge
improvement.

Be sure to have this field be well defined near leap seconds though. IIRC,
the number should increment at the start of the leap second in UTC time,
but I've not thought that through completely and since all simple things
with leapseconds are harder than you think, best to be clear so everyone
knows and any 'simple' mistakes are caught in review :) Having it only
be approximate near the leap second would be a really really bad
idea... Better to say '0' 30s either side of a leap second than to have
it be broadcast incorrectly for a few seconds after...

Warner