Re: [Ntp] NTPv5: big picture

[Hal Murray <[e-mail]>]

[e-mail] said:
> 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. 

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.




-- 
These are my opinions.  I hate spam.