Re: [Ntp] Antw: [EXT] Re: Quick review of WGLC for status change for draft-ietf-ntp-update-registries

[Harlan Stenn <[e-mail]>]

On 8/17/2022 1:45 AM, Miroslav Lichvar wrote:
> On Tue, Aug 16, 2022 at 04:44:31AM -0700, Harlan Stenn wrote:
>> On 8/16/2022 3:57 AM, Miroslav Lichvar wrote:
>>> I'd expect most people to assume that the version field indicates the
>>> protocol version, same as for the timing modes.
>>
>> OK, and the significant bit there is "I'd expect".
>>
>> And "protocol version" - exactly what does that mean?
> 
> The network protocol which the server and client need to support in
> order to correctly exchange data.

I believe server and client need more context here.  Specifically, I 
believe it is a good idea to treat timing modes and control modes 
separately.

And IMO it's more than just the packet layout.

>> what is the benefit of bumping the packet version in mode 6 (and probably
>> mode 7) packets?
> 
> If there are no changes in the protocol, then it doesn't make sense to
> increase the version number. This would be a good reason for keeping
> the mode-6 specification separate from the rest.
 >
>> An argument can be made that if backward incompatible changes are made to
>> the mode 6 "protocol" (and I use that term loosely) then at that point it
>> makes sense to bump the version number in the header.
> 
> Yes, exactly. And I expect the same for the timing NTP modes.

I believe that's what has already been done.  For the timing modes:

v2 to v3 changed a variable in the packet header.

v3 to v4 added extension fields.

>>> I like how it explicitly says that servers are not supposed to respond
>>> to unsupported versions.
>>
>> So the reference implementation seems to clearly implement this.
> 
> Yes and I find it interesting that it can do that for mode 6 and 7, but
> not the other modes.

The timing modes are different.

As I have said many times, the design of the timing modes and the packet 
structure allows NTP to reply to packets of lesser, equal, or greater 
version numbers and "it just works".  Or it would, for future packet 
versions if future versions followed the design and either APPENDED new 
fields to the older base packet, or even better, used EFs to encapsulate 
new fields.

Your NTPv5 work is explicitly breaking that rule, and y'all are 
apparently only recently beginning to see some of the consequences of 
that choice.

>> What are the pros/cons of responding (or not) to an unknown version?  I
>> would think this would be something to consider when there is an actual
>> use-case.
> 
> Responding to an unknown version leads to problems when the new
> version is not compatible.

Yes.  That's a consequence of incompatibility.  The only way to change 
this in existing code is to replace the old code.  Good luck with that.

 > You seem to agree that protocol versions
 > should change only on incompatible changes.

I think you are taking excessive license with my POV.

A v4 timing packet without EFs is *identical* to a v3 packet.

This is fine, because (as I recall) 5906 says the presence of an EF 
means a MAC MUST be attached to the packet.  That requirement got 
unilaterally dropped in 7822 because of 7821.  You may recall I gave 
negative feedback about how this was done.

The packet changes in v5 go way beyond previous changes, when it comes 
to incompatibility.

> If the version can change for other reasons and the unknown version
> turns out to be compatible, then responding to the unknown version
> avoids the need to update the code. That's the only advantage I see.

There you go again.

In the past, there was a conscious plan that bumping the timing (at 
least) version number implied additional and POSSIBLY incompatible 
packet changes.

But I've talked about the differences between v3 and v4 above, and these 
incompatibilities are, from everything I can see, non-issues.

That is NOT the case with the v5 proposals and previous versions.

But I note I'm now not certain if I correctly parsed your first sentence 
immediately above.

It's not clear to me what or how long it will take for a v5 client to 
detect and remediate an attempt to talk to a v4 server.

It's not clear to me what or how long it will take a v4 client to detect 
and remediate an attempt to get time from a v5 server that does not 
respond to the v4 request.

There are a lot of people who Care Very Much about getting their clocks 
sync'd quickly and well at startup.

>>> Are there any client implementations using the NTPv4 control mode?
>>
>> Do you mean ntpsnmpd?  Something else?
> 
> ntpsnmpd seems to be reusing the ntpq code, i.e. it uses NTPv2.

So what?  ntpsnmpd is a direct and clear example of a client 
implementation using the NTPv4 control mode.

But maybe you meant "is anybody using v4 in the header of a mode 6 command?

If that is, indeed, what you are asking, then no, I'm not aware of 
anything.  But how does that matter?

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!