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> Thu, 11 August 2022 12:11 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 58645C14CF01 for <ntp@ietfa.amsl.com>; Thu, 11 Aug 2022 05:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Level:
X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 zO4ScvH5r1Kn for <ntp@ietfa.amsl.com>; Thu, 11 Aug 2022 05:11:09 -0700 (PDT)
Received: from chessie.everett.org (unknown [IPv6:2001:470:1:205::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 C0B6BC14F735 for <ntp@ietf.org>; Thu, 11 Aug 2022 05:11:09 -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 4M3Qd51ZQ9zMP49; Thu, 11 Aug 2022 12:11:05 +0000 (UTC)
Message-ID: <5912fc71-2849-e1a6-20ca-61c2cfcb6e32@nwtime.org>
Date: Thu, 11 Aug 2022 05:11:04 -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: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "ntp@ietf.org" <ntp@ietf.org>, martin.burnicki@meinberg.de
Cc: halmurray@sonic.net
References: <20220809030711.F00DC28C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <7eef9a6f-a115-b009-24e5-2b96a8bc02ae@meinberg.de> <62F23E8A020000A10004C393@gwsmtp.uni-regensburg.de> <1adca9bf-81fa-189f-ae13-47c049e02721@meinberg.de> <7a445ad1-f93c-8c18-834c-503c60f17911@nwtime.org> <62F4E496020000A10004C47F@gwsmtp.uni-regensburg.de>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <62F4E496020000A10004C47F@gwsmtp.uni-regensburg.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/8v054sFalKUYjL0NcKIDObG7gMA>
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: Thu, 11 Aug 2022 12:11:14 -0000

On 8/11/2022 4:14 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <stenn@nwtime.org> schrieb am 11.08.2022 um 12:43 in Nachricht
> <7a445ad1-f93c-8c18-834c-503c60f17911@nwtime.org>:
>> On 8/9/2022 4:11 AM, Martin Burnicki wrote:
> ...
>> The design is that the base packet for a given NTP protocol stays the
>> same for future protocol versions.  If new info is wanted, it is
>> APPENDED to the packet.  The easiest way to get new stuff there might be
>> to use EFs, rather than by changing the base packet format and size.
> ...
> 
> Such design may work for some time, but once all the old fields have no practical use any more, they are just dead payload.

That assumes there will be a time where all the old fields have no 
practical use anymore.

> An NTPv3 or v4 client could not use such new "extended" packets anyway, right? Or do you append the new stuff _after_ the MAC?

Are you talking about a legacy MAC or a MAC-EF?

Legacy implementations do not know about MAC-EF.

But v3 packets are not wired for EFs, and for backward compatibility 
with v4, the v4 packet structure should be used.  This means new fields 
should be put in as EFs.

> If so, you are essentially sending two protocol packets in one transport frame. I wouldn't name that "append", however.
> 
> Regards,
> Ulrich
> 
> 
> 

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