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

Harlan Stenn <stenn@nwtime.org> Tue, 16 August 2022 11:48 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 E2C14C15AE22 for <ntp@ietfa.amsl.com>; Tue, 16 Aug 2022 04:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 nwN2xld0pTkx for <ntp@ietfa.amsl.com>; Tue, 16 Aug 2022 04:48:10 -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 1D600C1522AF for <ntp@ietf.org>; Tue, 16 Aug 2022 04:48:10 -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)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4M6TtK5DybzMNZM; Tue, 16 Aug 2022 11:48:09 +0000 (UTC)
Message-ID: <ce02ea92-91ef-ac24-797b-8381caa2bfe5@nwtime.org>
Date: Tue, 16 Aug 2022 04:48:08 -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> <da155c84-2c70-2e3b-59eb-03e380806cf2@nwtime.org> <PH0PR06MB70611F2331D8255F7E2B6604C2999@PH0PR06MB7061.namprd06.prod.outlook.com> <0b4c7efa-3977-b588-0974-33b6a9437e52@nwtime.org> <YvDWC27qKnODlD52@localhost> <0b57b7db-772e-f5e6-e6a0-a433673f3d77@nwtime.org> <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>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <22DC6703-ADFA-45BA-B26D-3DB7E957D0F3@meinberg.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/knMBxzS5RyTmmg8TgSbdKl-JLe8>
Subject: Re: [Ntp] 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: Tue, 16 Aug 2022 11:48:16 -0000

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?

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