[Ntp] Re: NTP Extension Field additions, and IANA NTP table management process

Harlan Stenn <stenn@ntp.org> Thu, 20 February 2025 00:20 UTC

Return-Path: <stenn@ntp.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 65DDDC1CAE74 for <ntp@ietfa.amsl.com>; Wed, 19 Feb 2025 16:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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=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 Rse1mPw6_n8F for <ntp@ietfa.amsl.com>; Wed, 19 Feb 2025 16:20:04 -0800 (PST)
Received: from chessie.everett.org (chessie.fmt1.pfcs.com [66.220.13.234]) by ietfa.amsl.com (Postfix) with ESMTP id 7F90CC14F713 for <ntp@ietf.org>; Wed, 19 Feb 2025 16:19:59 -0800 (PST)
Received: from [10.208.75.149] (syn-075-139-201-040.res.spectrum.com [75.139.201.40]) (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 4YytvJ42drzMQbL; Thu, 20 Feb 2025 00:10:36 +0000 (UTC)
Message-ID: <d90b0c60-0d34-4869-b7f5-eeee887ff492@ntp.org>
Date: Wed, 19 Feb 2025 16:10:37 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Hal Murray <halmurray@sonic.net>
References: <20250219192329.CE3BC620173@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
Content-Language: en-US
From: Harlan Stenn <stenn@ntp.org>
In-Reply-To: <20250219192329.CE3BC620173@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: 3CPJG4QVTNSFHE5T2AMXGDDCVXHWL2GP
X-Message-ID-Hash: 3CPJG4QVTNSFHE5T2AMXGDDCVXHWL2GP
X-MailFrom: stenn@ntp.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ntp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Miroslav Lichvar <mlichvar@redhat.com>, ntp@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Ntp] Re: NTP Extension Field additions, and IANA NTP table management process
List-Id: Network Time Protocol <ntp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/0_Dd5S-v6bee3-GKcqsM5QloX28>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Owner: <mailto:ntp-owner@ietf.org>
List-Post: <mailto:ntp@ietf.org>
List-Subscribe: <mailto:ntp-join@ietf.org>
List-Unsubscribe: <mailto:ntp-leave@ietf.org>

On 2/19/2025 11:23 AM, Hal Murray wrote:
> 
> stenn=40ntp.org@dmarc.ietf.org said:
>> I don't understand.  Are you saying that 256 type may not be enough for
>> NTPv4?
> 
> If Miroslav hadn't said it, I would have.
> 
> Running out of slots in any table is a really bad idea.  Nothing in recent
> history tells us that there won't be an explosion of allocations tomorrow.
>   I don't have any suggestions to change (or "fix") anything, but I will
> object to any arguments along the lines of 256 is plenty.

And my response would be the same.

You are both worried about something that MIGHT happen, and want to make 
preemptive changes without consideration of the real cost of those changes.

I believe "you" are responding and acting out of a fear of what might 
happen, and the "fix" you want to implement now will LIMIT choices down 
the road.

Do you see any problem with the Extended Extension Field thing I 
described in previous emails?

>> The working group is already talking about v5, and v5 can change the EF
>> stuff in any way it wants.
> 
> The current plan is to use the same table for V5 and ...

Sure.  And think about the word "current".

If things pan out so this turns out to be a bad idea, v5 MAY choose to 
use a different format, even if it turns out to be a superset of the v4 
EF table.

-- 
Harlan Stenn <stenn@ntp.org>
NTP Project Lead.  The NTP Project is part of
https://www.nwtime.org/ - be a member!