Re: [Ntp] NTPv5: big picture

[Philip Prindeville <[e-mail]>]

> On Jan 4, 2021, at 8:18 AM, Miroslav Lichvar <[e-mail]> wrote:
> 
> 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.


I disagree.  The kernel doesn’t inherently require UTC.  It could just as easily use TAI or some other format.

The kernel needs to provide into user-space some format which is then convertible to UTC, for as long as UTC is in-use by applications.

This could be handled by libc.

-Philip


> 
> 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
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp