Re: [Ntp] NTPv5: big picture

[Magnus Danielson <[e-mail]>]

Hal,

On 2021-01-01 03:54, Hal Murray wrote:
> Do we have a unifying theme?  Can you describe why we are working on NTPv5 in 
> one sentence?
>
> I'd like to propose that we get rid of leap seconds in the basic protocol.

Define "get rid off". Do you meant you want the basic protocol to use a
monotonically increasing timescale such as a shifted TAI? If so, I think
it would make a lot of sense.

If it is about dropping leap second knowledge, it does not make sense.

>
> Unfortunately, we have a huge installed base that works in Unix time and/or 
> smeared time.  Can we push supporting that to extensions?  Maybe even a 
> separate document.
Mapping of NTPv5 time-scale into (and from!) NTP classic, TAI, UTC,
UNIX/POSIX, LINUX, PTP, GPS time-scales is probably best treated
separately, but needs to be part of the standard suite.
>
> --------
>
> Part of the motivation for this is to enable and encourage OSes to convert to 
> non-leaping time in the kernels.  Are there any subtle details in this area 
> that we should be aware of?  Who should we coordinate with?  ...

I think that would be far to ambitious to rock that boat.

Kernels already operate with a double vision and have ways to handle
both non-leaping time and leapsecond in parallel.

>
> ---------
>
> I think this would bring out another important area: How does a client 
> discover if a server supports an option and/or discover servers that do 
> support it?
The solution that works for other protocols is that you ask for
capabilities (or you get them served as part of basic handshake). This
is typically a text-string of well defined capability names. Set of
constants or set of bits have also been seen.
>
> I'd like the answer to be authenticated.  It seems ugly to go through NTS-KE 
> if the answer is no.

Do not assume you have it, prefer the authenticated answer when you can
get it. I am not sure we should invent another authentication scheme more.

Let's not make the autokey-mistake and let some information be available
only through an authentication scheme that ended up being used by very
few. You want to have high orthogonality as you do not know what lies ahead.

So, we want to be able to poll the server of capabilities. Remember that
this capability list may not look the same on un-authenticated poll as
for authenticated poll. It may provide authentication methods, hopefully
one framework fits them all, but we don't know. As you ask again you can
get more capabilities available under that authentication view. Another
configuration or implementation may provide the exact same capabilities
regardless of authentication.

>   Maybe we should distribute the info via DNS where we can 
> use DNSSEC.

Do no assume you have DNS access, the service cannot rely on that. It
can however be one supplementary service. NTP is used in some crazy
places. Similarly with DNSSEC, use and enjoy it when there, but do not
depend on its existence.

When DNS is available, what additional values can be put there to aid
validation and service?

> Again, that can be a separate document.

Sure. I think the final word on slicing and dicing of documents becomes
an issue once the parts are done. I think one should not focus too much
on it, as it will become apparent later in the process what will make
most sense.

Cheers,
Magnus