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

[Miroslav Lichvar <[e-mail]>]

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.

> 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 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.

> 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. You seem to agree that protocol versions
should change only on incompatible changes.

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.

> > 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.

-- 
Miroslav Lichvar