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

Harlan Stenn <stenn@nwtime.org> Wed, 17 August 2022 09:50 UTC

Return-Path: <stenn@nwtime.org>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF47C14CE40 for <ntp@ietfa.amsl.com>; Wed, 17 Aug 2022 02:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwC5QNi3e8Je for <ntp@ietfa.amsl.com>; Wed, 17 Aug 2022 02:49:58 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9C4C14CF00 for <ntp@ietf.org>; Wed, 17 Aug 2022 02:49:58 -0700 (PDT)
Received: from [10.208.75.149] (071-084-168-128.res.spectrum.com [71.84.168.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4M73CT659xzMP5c; Wed, 17 Aug 2022 09:49:57 +0000 (UTC)
Message-ID: <2f7c231b-e926-a31c-3818-780b69d1ce37@nwtime.org>
Date: Wed, 17 Aug 2022 02:49:57 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
To: Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>, Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>, "ntp@ietf.org" <ntp@ietf.org>
References: <PH0PR06MB7061FA7A5B338D262B3A2963C2999@PH0PR06MB7061.namprd06.prod.outlook.com> <YvED7T5R0UsRWbv3@localhost> <b64c6a0a-ea2e-0a19-4bb9-38bfaa2e5032@nwtime.org> <656D355F-E06A-4005-B9D6-90885FA8509D@akamai.com> <1a4bae28-f0f3-e675-899a-bad597b4ee29@nwtime.org> <F74A7B5B-3D77-42AF-BD7E-1A874CCD2D66@akamai.com> <67545c9a-3291-bbe6-c876-4c762c80c710@nwtime.org> <FF22AEFE-ED61-405E-AB40-B7901D0CD588@meinberg.de> <f79cecd6-92b0-595b-e449-6b6f8944ae66@nwtime.org> <133C5633-E4D5-42AF-8215-E3FDE28C5BF9@meinberg.de> <4f833218-231f-8c47-e529-b3ba00f6554e@nwtime.org> <62FB5EDB020000A10004C5CD@gwsmtp.uni-regensburg.de> <a89aeba9-5e88-2214-634f-7a9a7106eec3@nwtime.org> <22DC6703-ADFA-45BA-B26D-3DB7E957D0F3@meinberg.de> <ce02ea92-91ef-ac24-797b-8381caa2bfe5@nwtime.org> <156A19AA020000CE86EDC2A6@gwsmtp.uni-regensburg.de> <17F56E700200003C822C0D04@gwsmtp.uni-regensburg.de> <62FC9492020000A10004C619@gwsmtp.uni-regensburg.de> <7CBEFEA1-1049-4023-BC4A-7B5FCEE20058@meinberg.de>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <7CBEFEA1-1049-4023-BC4A-7B5FCEE20058@meinberg.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/FJRiHsCmdk9dejV1h6sgf9p5j7o>
Subject: Re: [Ntp] Antw: Re: Antw: [EXT] Re: Quick review of WGLC for status change for draft-ietf-ntp-update-registries
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2022 09:50:04 -0000

On 8/17/2022 2:27 AM, Heiko Gerstung wrote:
> 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;
> 
> 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.
> 
> 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.

Yes and no.  If one asks for a variable that is not there, one gets an 
error response.

So it's not difficult to probe around and figure out what's going on.

But I think this is not the best behavior, and we're working on 
improvements.  Some of these will likely show up in ntp-4.4, with 
additional changes in ntp-4.6.

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

I suspect that's not the main reason.  I suspect that given one can ask 
for variables and learn what is there and what is not, it wasn't seen as 
a big deal.

I think the bigger deal is that we don't have a standardized list of
"core" data items, and a means to make a "what can you tell me?" query, 
or easily figure out version and/or implementation-specific items.

This then gets in to privilege layers, authentication, and authorization 
stuff.

It is intricate, and it's not yet clear how many folks really care, or 
how much they care.  And what they are (not) prepared to do in order to 
get it.

> Regards,
>     Heiko
> 
> 
> 
> 
> 
> 
> Am 17.08.22, 09:11 schrieb "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>:
> 
>      >>> Harlan Stenn <stenn@nwtime.org> schrieb am 16.08.2022 um 13:48 in
>      Nachricht
>      <ce02ea92-91ef-ac24-797b-8381caa2bfe5@nwtime.org>:
>      > 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: +49 (0)5281 9309-404 | LinkedIn Profile
>      > <https://www.linkedin.com/in/heikogerstung/> | Twitter
>      > <https://twitter.com/hgerstung>
>      >> heiko.gerstung@meinberg.de
>      >>
>      >> 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"
>      > <ntp-bounces@ietf.org im Auftrag von stenn@nwtime.org>:
>      >>
>      >>      On 8/16/2022 2:09 AM, Ulrich Windl wrote:
>      >>      >>>> Harlan Stenn <stenn@nwtime.org> schrieb am 15.08.2022 um 23:53 in
> 
>      > Nachricht
>      >>      > <4f833218-231f-8c47-e529-b3ba00f6554e@nwtime.org>:
>      >>      > ...
>      >>      >> 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 <stenn@nwtime.org>
>      >>      http://networktimefoundation.org - be a member!
>      >>
>      >>      _______________________________________________
>      >>      ntp mailing list
>      >>      ntp@ietf.org
>      >>      https://www.ietf.org/mailman/listinfo/ntp
>      >>
>      >>
>      >> _______________________________________________
>      >> ntp mailing list
>      >> ntp@ietf.org
>      >> https://www.ietf.org/mailman/listinfo/ntp
>      >
>      > --
>      > Harlan Stenn <stenn@nwtime.org>
>      > http://networktimefoundation.org - be a member!
> 
> 
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!