Subject: [Ntp] NTPv5: big picture

From: Hal Murray <[email-masked]>
Date: Thu, 31 Dec 2020 18:54:40 -0800

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.

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.

--------

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

I'd like the answer to be authenticated.  It seems ugly to go through NTS-KE 
if the answer is no.  Maybe we should distribute the info via DNS where we can 
use DNSSEC.

Again, that can be a separate document.

-- 
These are my opinions.  I hate spam.

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 1 Jan 2021 04:35:04 +0100

Hal,

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

> smeared time.  Can we push supporting that to extensions?  Maybe even a 
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.
> 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.

> discover if a server supports an option and/or discover servers that do 
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.
> 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

---

From: Hal Murray <[email-masked]>
Date: Thu, 31 Dec 2020 21:53:26 -0800

[email-masked] said:
> monotonically increasing timescale such as a shifted TAI? If so, I think it
> would make a lot of sense. 

I'd like the basic document not to include the words "leap second", except 
possibly for a chunk that says we-don't-do-that, look-over-there.

I didn't say TAI because I don't know enough about the politics of using that 
term.

My straw man is that POSIX time, UTC, leaping, and smearing should be moved to 
extensions and they be described in a separate document.

[moving leaps out of kernels]
> I think that would be far to ambitious to rock that boat.

Yes, but if everybody says that nothing will ever happen.

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

My (Linux) man page has various options for clock_gettime(), but it doesn't 
say anything about leap seconds or TAI.  Yes, it should be reasonable to add, 
but it's not there yet.

[options]
> 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.

That works fine for cases like SMTP or HTTP where it represents a minor 
fraction of the overall workload.  The usual context is the client can get 
their work done without the new feature but do things better if they use 
new/optional features.  In the context of NTP, we don't want to use a server 
if it doesn't support a feature we need.  It would be better to discover that 
without going through NTS-KE.

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

An important difference between NTP exchanges and feature requests is that the 
available features change very slowly.

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

Yes, but it we take that approach then we have to consider all the 
opportunities for the bad guy to forge answers so we get downgraded to a 
less-good mode of operation.

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

I'm happy for a config file to use numeric IP Addresses rather than host names.

I think that can be made to work with NTS but I haven't tried it.