[Ntp] Antw: [EXT] Re: NTPv5 draft

[Ulrich Windl <[e-mail]>]

>>> Warner Losh <[e-mail]> schrieb am 07.12.2020 um 21:06 in Nachricht
<[e-mail]>:
> On Mon, Dec 7, 2020 at 12:12 PM Hal Murray <[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.

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


> 
> Warner