Re: [Ntp] Antw: Re: Antw: [EXT] A different NTPv5 design

[Miroslav Lichvar <[e-mail]>]

On Thu, Apr 30, 2020 at 01:04:49PM +0200, Ulrich Windl wrote:
> So autokey V2 uses a single "field type" (2), but several "Codes" (and R|E
> variants). As the protocol changes a lot more "field types" will be consumed. I
> think it was a very bad idea to pollute the field type namespace that way.

Ok. This is the old issue in how the field type is interpreted
differently in different contexts. For NTPv5 we can specify it any way
as long as it's consistent with the types that were already assigned.
There are not that many of them. I assume we don't want to assign new
NTPv5-specific types to the existing NTPv4 extension fields.

Of course, implementations that want to support NTPv5 will need
conform to the specification in how they interpret the field to
prevent a new extension field to be mismatched. I don't see a problem
here.

> > Is 14 days not enough in advance? The timestamp could be in an
> > extension field if it needs to be provided.
> 
> It sounds more like the minimum. I feel like it SHOULD be 30 days at least.

There was a time (before RFC 5905) when ntpd announced it whole month
before. That lead to the leap indicator getting stuck as there was no
period where it should be unset. I'd rather not risk that happening
again.

> > I don't follow. How would a transition phase help? Clients either
> > support NTPv5 and can process an NTPv5 response with the modified
> > fields, or not. Existing servers already have all information needed
> > to support NTPv5 and can easily do so.
> 
> The transition phase might help some bad clients that disregard the version
> field, misinterpreting data.
> (Yes, NTPv3 is still active)

I still don't follow. A client won't get an NTPv5 response unless it
makes an NTPv5 request. Old clients will work exactly as before. It
was the same with the NTPv3->NTPv4 transition.

I'm not sure how much should we care about buggy clients, anyway.

> > No, it's an enumeration with 8 possible values. It wouldn't make sense
> > for a client to request two or more timescales at once.
> 
> OK, I see they are mutually exclusice that way. Is an agreement protocol for a
> common timestamp format needed?

The timescale field is the whole protocol. If a client wants to get
timestamps in TAI, it will set the field to the value corresponding to
TAI. If the server supports it, it will respond with the same value in
the field. If it doesn't support it, it will respond with a different
value and the client can either accept the timestamps in the other
timescale or ignore the response (and switch to another server if it's
a pool for example).

> Will there be versions > 7 ever?

It could be, but it would need to be saved in a different field. 7
would mean "go look elsewhere".

-- 
Miroslav Lichvar