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

[Ulrich Windl <[e-mail]>]

>>> Heiko Gerstung <[e-mail]> schrieb am 17.08.2022 um 11:27
in
Nachricht <[e-mail]>:
> The code (ntp.h) uses this define:
> #define NTP_OLDVERSION  ((u_char)1) /* oldest credible version */
> 
> And ntpq (ntpq.c) sets the packet version like this:
> /*
>  * Packet version number we use
>  */
> u_char pktversion = NTP_OLDVERSION + 1;

Well, one can speculate: NTPv2 was the first one that defined the control
message protocol, so maybe "OLD" was just intended to mean "previous", or
specifically "not the old protocol that had no version number (and no control
messages)".

Page 49 of RFC1119 (PS/PDF version) states: "Version Number (VN): This is a
three-bit integer indicating the NTP version number, currently two
(2)." So it seems it was intended that the version matches the protocol
version even in control messages.

> 
> It looks like the ntpq code deliberately takes the "oldest credible version"

> and increases it by one, which results in the "second oldest credible 
> version" if I am not wrong. I agree with Harlan that you do not need to bump

> a version number if the format is the same, but I also agree with the 
> assumption that ntpq/mode6 should use its own version numbering and bump the

> version if a query or response changes. The general packet format still
works 
> fine, but the contents can change. 

I think the control messages should have their own variable defining the
message version; 3 bits is not enough, specifically as there are only three
states (5-7) left.

> 
> The examples of variable names changing (root dispersion/root disp) is a 
> good example for a "breaking change" as it most likely would break a parser

> that tries to read a value and process it. 
> 
> To me the main reason why this version number never changed, despite the 
> fact that the content of the mode 6 packets did, is that the VN refers to
the 
> packet format itself, not to the content. Therefore, if we ever get to a 
> point where we define a standardized mode 6 interface, we would need a 
> version number for the content/data provided by the NTP instance. 

My opinion is different. See above.

Regards,
Ulrich

> 
> Regards,
>    Heiko
> 
> 
> 
> 
> 
> 
> Am 17.08.22, 09:11 schrieb "Ulrich Windl" 
> <[e-mail]>:
> 
>     >>> Harlan Stenn <[e-mail]> schrieb am 16.08.2022 um 13:48 in
>     Nachricht
>     <[e-mail]>:
>     > On 8/16/2022 4:09 AM, Heiko Gerstung wrote:
>     >> The RFC says
>     >> " VN Version Number (version): 3-bit integer representing the NTP
>     >>     version number, currently 4."
>     >> 
>     >> It does not make any exceptions for different modes, so why should
the 
>     > meaning of the version number field be different for mode 6 packets? I

> did 
>     > not find anything in RFC5905 about mode 6 packets.
>     > 
>     > Yes, and it also talks about "recognized" versions.
>     > 
>     > If, over the years, mode 6 packets going out as v2 interoperate 
>     > sufficiently with ntp-[234] target systems, what are the
costs/benefits 
> 
>     > of (arbitrarily?) bumping the version number as new ntpN releases are

> made?
> 
>     Let me ask the other way: Setting VN=4 for mode 6 queries is answered 
> just the
>     same. Maybe it was just forgotten to touch the code for the new
version.
> 
>     > 
>     >> Regards,
>     >>    Heiko
>     >> 
>     >> --
>     >> Heiko Gerstung | Managing Director
>     >> T: [phone] | LinkedIn Profile 
>     > <https://www.linkedin.com/in/heikogerstung/> | Twitter 
>     > <https://twitter.com/hgerstung>
>     >> [e-mail] 
>     >> 
>     >> MEINBERG® The Synchronization Experts
>     >>   
>     >> Meinberg Funkuhren GmbH & Co. KG
>     >> Lange Wand 9 | 31812 Bad Pyrmont | Germany
>     >> Web: http://www.meinberg.de | http://www.meinbergglobal.com |
LinkedIn  
> 
>     > <https://www.linkedin.com/company/meinberg-funkuhren-gmbh-&-co--kg>
>     >> 
>     >> Amtsgericht Hannover 17HRA 100322
>     >> Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
>     > Hartmann, Heiko Gerstung
>     >> 
>     >> Do not miss our Time Synchronization Blog:
>     >> http://blog.meinbergglobal.com 
>     >>   
>     >>   
>     >> 
>     >> Am 16.08.22, 11:22 schrieb "ntp im Auftrag von Harlan Stenn" 
>     > <[e-mail] im Auftrag von [e-mail]>:
>     >> 
>     >>      On 8/16/2022 2:09 AM, Ulrich Windl wrote:
>     >>      >>>> Harlan Stenn <[e-mail]> schrieb am 15.08.2022 um
23:53 in
> 
>     > Nachricht
>     >>      > <[e-mail]>:
>     >>      > ...
>     >>      >> So if we're a V4 server and we get a v5 request, we will
respond
>     with 
>     > a
>     >>      >> v4 packet that says v5.
>     >>      >>
>     >>      >> This is consistent with the design.
>     >>      >>
>     >>      >> No one has seen a v1 packet format in a very long time.  The
v1
>     stuff
>     >>      >> folks are seeing now are v[234] packets claiming to be v1.
>     >>      >>
>     >>      >> The format of the base packet saw a slight change going from
v2 
> to
>     v3
>     >>      >> (sync dispersion was replaced by estimated drift rate), and
there
>     was
>     >>      >> (TTBOMK) no change to the base packet from v3 to v4.
>     >>      >>
>     >>      >> The change from v2 to v3 caused no problems that I can
recall, 
> and
> 
>     > even
>     >>      >> so, I'm unaware of ANY surviving v2 servers out there.
>     >>      >
>     >>      > Well, ntpq 4.2.8p15 is using version==2 when doing mode 6 
> queries,
>     so 
>     > there are V2 packets!
>     >> 
>     >>      What exactly does the version field mean in a mode 6 packet?
>     >> 
>     >>      --
>     >>      Harlan Stenn <[e-mail]>
>     >>      http://networktimefoundation.org - be a member!
>     >> 
>     >>      _______________________________________________
>     >>      ntp mailing list
>     >>      [e-mail] 
>     >>      https://www.ietf.org/mailman/listinfo/ntp 
>     >> 
>     >> 
>     >> _______________________________________________
>     >> ntp mailing list
>     >> [e-mail] 
>     >> https://www.ietf.org/mailman/listinfo/ntp 
>     > 
>     > -- 
>     > Harlan Stenn <[e-mail]>
>     > http://networktimefoundation.org - be a member!