Re: [Ntp] NTPv5: big picture

[Dieter Sibold <[e-mail]>]

On 4 Jan 2021, at 16:18, Miroslav Lichvar 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.
>
> 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.

If security-by-default is enforced the NTS-KE could serve as a robust 
mean to exchange the server’s capabilities.




>
> -- 
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp