Re: [Ntp] NTPv5: big picture

[Miroslav Lichvar <[e-mail]>]

On Thu, Dec 31, 2020 at 06:54:40PM -0800, Hal Murray wrote:
> 
> Do we have a unifying theme?  Can you describe why we are working on NTPv5 in 
> one sentence?

There is a list of issues in NTPv4 I would like to see fixed in NTPv5:
https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues

A major issue is that NTPv4 doesn't support short extension fields due
to conflicts with legacy MACs, so fixing all those issues by adding
new extending fields to NTPv4 seems impractical. Some things, e.g. the
timescale selection, makes more sense to have in the header.

> 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 don't think that should be the job of the NTP WG. The kernels will
need to support a leaping UTC timescale for as long as it is needed
for civil time.

NTP should keep support for the existing use cases. It is a protocol
for exchanging timestamps. The client and server need to agree on the
timescale. If both have support for TAI, that's great. They can use it
to avoid ambiguous timestamps around leap seconds. But this shouldn't
be a requirement. NTP needs to support UTC and it needs to announce
leap seconds before they happen. Forcing some servers or clients to
implement an unreliable TAI clock on top of an UTC clock only to make
NTP slightly simpler is not a good idea.

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

With most options I think the client can simply send a request using
that option and see if the server's response has it. It can do that
with every request, or try it only occasionally to reduce the average
length of the request and response.

For more complex or conflicting features, the support can be indicated
with a flag in an extension field.

-- 
Miroslav Lichvar