Subject: Re: [Ntp] NTPv5 draft

From: Hal Murray <[email-masked]>
Date: Mon, 07 Dec 2020 11:12:29 -0800

> But much of that info need not be at the lowest-level time authentication
> bootstrapping since there's overlap with other areas and services (the tz
> database, for example).

I think an RFC for NTPv5 should collect things like that.  The particular one 
that sentence brings up is leap-seconds.

It's a long way from Paris to my desktop.  I don't thing an RFC has to totally 
solve that particular problem, but if it doesn't provide a good solution, it 
should have a section that describes the problem, explains what it does 
provide and what it expects some part of the environment to provide.

-- 
These are my opinions.  I hate spam.

---

From: Warner Losh <[email-masked]>
Date: Mon, 7 Dec 2020 13:06:41 -0700

> provide and what it expects some part of the environment to provide.

For leap seconds in particular, whatever solution you come up with has to
cope with 'late' discovery of leap seconds in a way that's at least
predictable, even if there's uncertainty until you have final knowledge.
The problem need not be solved entirely, but some reasonable bounds can be
used so the 'typical' error from leap seconds falls within those bounds as
an 'ordinary error' to the largest degree possible.

Warner

---

From: Doug Arnold <[email-masked]>
Date: Mon, 7 Dec 2020 22:03:20 +0000

I think that if a client or server has been up and running long enough to get through any start up transients, it should be able to handle a leap second event smoothly.  However, I don’t think that things need  be glitch free for some pathological case, such as an client or server that gets turned on right before a leap second event.

Doug

From: ntp <[email-masked]> on behalf of Warner Losh <[email-masked]>
Date: Monday, December 7, 2020 at 3:07 PM
To: Hal Murray <[email-masked]>
Cc: NTP WG <[email-masked]>
Subject: Re: [Ntp] NTPv5 draft

For leap seconds in particular, whatever solution you come up with has to cope with 'late' discovery of leap seconds in a way that's at least predictable, even if there's uncertainty until you have final knowledge. The problem need not be solved entirely, but some reasonable bounds can be used so the 'typical' error from leap seconds falls within those bounds as an 'ordinary error' to the largest degree possible.

Warner

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Dec 2020 10:40:13 +0100

>>> Warner Losh <[email-masked]> schrieb am 07.12.2020 um 21:06 in Nachricht
> an 'ordinary error' to the largest degree possible.

Hi!

It would be perfect if NTP could distribute the leapsecond table authenticated, so clients would be informed way ahead of the leap second event. For those not having (or willing to have) a leap second table it has to be specified precisely how to interpret thge LI bits.
IMHO the leap announcement should be at least one day ahead (considering maxpoll), and probably NTPv5 could demand that any leap second announcement needs an extension that specifies the leap event (in NTP time?). So at least any future implementations would have no doubt when exactly the leap second will happen.

Regards,
Ulrich