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:55 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 295C8C1522B1 for <ntp@ietfa.amsl.com>; Tue, 16 Aug 2022 04:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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=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 aGpN_z_aTj5F for <ntp@ietfa.amsl.com>; Tue, 16 Aug 2022 04:55:18 -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 1217FC14F723 for <ntp@ietf.org>; Tue, 16 Aug 2022 04:55:18 -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 4M6V2Y5CrFzMNZM; Tue, 16 Aug 2022 11:55:17 +0000 (UTC)
Message-ID: <21083de4-34e0-3c58-9478-eb2116ecc5b1@nwtime.org>
Date: Tue, 16 Aug 2022 04:55:16 -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> <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> <5149BD55-E4A2-40B9-AFB1-9F69AAA319C8@meinberg.de>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <5149BD55-E4A2-40B9-AFB1-9F69AAA319C8@meinberg.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/pi9b0Bn7osm6i3LtLJTSOHGjR-k>
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:55:22 -0000

On 8/16/2022 4:18 AM, Heiko Gerstung wrote:
> OK, I checked and found out that the ntpq tool in 4.2.8p13 is sending all queries with VN=2 - therefore ntpd is responding with the same version.
> 
> As it seems, there is no standard describing/defining mode 6 or mode 7, so maybe we should treat both as "vendor/implementation specific"?

Toward what goal?

The code has ALWAYS considered mode 6 to be base information that any 
implementation SHOULD/MUST support, and mode 7 as "vendor specific".

What are the costs and benefits of taking a new position that both 
should be treated as vendor/implementation specific?

I would think there would be great benefit to be had for a standardized 
management protocol for NTP.

H
--
> Regards,
>    Heiko
> 
> Am 16.08.22, 13:10 schrieb "ntp im Auftrag von Heiko Gerstung" <ntp-bounces@ietf.org im Auftrag von heiko.gerstung=40meinberg.de@dmarc.ietf.org>:
> 
>      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.
> 
>      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
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

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