Re: [Ntp] NTPv5 draft

[Doug Arnold <[e-mail]>]

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 <[e-mail]> on behalf of Warner Losh <[e-mail]>
Date: Monday, December 7, 2020 at 3:07 PM
To: Hal Murray <[e-mail]>
Cc: NTP WG <[e-mail]>
Subject: Re: [Ntp] NTPv5 draft



On Mon, Dec 7, 2020 at 12:12 PM Hal Murray <[e-mail]<mailto:[e-mail]>> wrote:

> 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.

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