[Ntp] Re: NTPv5: Operational use case for server/node identification
Ask Bjørn Hansen <ask@develooper.com> Wed, 22 July 2026 12:24 UTC
Return-Path: <ask@develooper.com>
X-Original-To: ntp@mail2.ietf.org
Delivered-To: ntp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 78E1B11C3EFB2 for <ntp@mail2.ietf.org>; Wed, 22 Jul 2026 05:24:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784723062; bh=zZHOHlrcHKKQg2sw2/w2stmMPDv5Ka4Aj47sMt2ptm0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=kF8jlphc6ufZlkU5Rf2zDQHohwyupjHKY1xGRbuhp/o5IkQuS0UfRPmPLdVZyAPWd fCIAcNHCDU+VdZKd0a+LDfYBXPgiTTsgT3FphNQH5DUBGG6fTrsUn+3/933NutVRjK j6oTbTVf4ISKgCjnd6NvkfPKvTlsIspmmGFYpAfw=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ntp.dev
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPyJYNyuEn8H for <ntp@mail2.ietf.org>; Wed, 22 Jul 2026 05:24:21 -0700 (PDT)
Received: from mail-out.ntp.dev (dala-ip122.sys.ntp.dev [104.225.13.122]) by mail2.ietf.org (Postfix) with ESMTP id 9B90811C3ED17 for <ntp@ietf.org>; Wed, 22 Jul 2026 05:24:11 -0700 (PDT)
Authentication-Results: mail-out.ntp.dev; dmarc=fail (p=quarantine dis=none) header.from=develooper.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntp.dev; s=mail-out-2; t=1784723043; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zZHOHlrcHKKQg2sw2/w2stmMPDv5Ka4Aj47sMt2ptm0=; b=y89SPsFncFUhx6+XgYvICQ4ZotAqoLy0Aa3DBG/rRgO0OtZwG/srUjCbpKk9nyzJmmApMj 3APGqEa3ETyl7nXHXY58PWMGcIKfXdFmeXKd2yydBGnwnVy4CvBLJ/dwCupLsZo//MiQYb nldlMD618GAiOAmA36ChEybVdv1peb+0I7C3M9fE3VpUjhoKv+jwde3VphIQld98D1bRuW Ikw6TrKcxMFA0JrzGZBE8UEbDIaomcivxg3ZIun8V6gQxoP3EfuXzq2mWfE+aLllCXdHYJ 94/yRpmH9OaYpiitGJPqfYvM0MUmdy8ocY2HBCRQEfnGb/5fnugpkGW+Q4R7jg==
ARC-Seal: i=1; s=mail-out-2; d=ntp.dev; t=1784723043; a=rsa-sha256; cv=none; b=FX2n/hLSB8HpkgxpTkcVe0k3yKRzUahSNonrGK/hIkA3+Mj/Ii/zZkgmOZXLFXO6HHP0ZD UhrA+hBrFs7gMCCzXYfxcFw8U3zzaoRdsyQkiuMCYP5oH/OuykFOKjHigMkcTNtRd4OGbl YS2K2hrvzulSof8pXjY7ulzFALnjc74ULMc9APu24EiCncm9Qku5d86r4qhqnhVmSlP5g8 eOK9QuM5Dn0gq7ngLHJIPPXsXZO3bBwpxzsRQ3pP5WTPFHjLSBiiH8JxfhG0v5O//WPfdL J5+Ih+JlaB2Ho29W5tzgwsAe3CDp6zOxPKYXlv46IX8pxrHEHWsGtwAnvt1oGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=ntp.dev; s=mail-out-2; t=1784723043; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zZHOHlrcHKKQg2sw2/w2stmMPDv5Ka4Aj47sMt2ptm0=; b=SKOOzIQzXDbhTXzofAWP+FGHewuPVXXzPQpAS5YrlQQdk150a7ioyA1TRQXntLxXoqRdhz aNopoCtsCScxqKzGd5LGYs+wOFR54CjUkZ4YO1urEGZS1vpHzpuxdq/sbuRxU7+ocKLEqs M7EuRKpx2U7yVj7ELURLTG8OGt7FgjqAs4/2egZn8ooMl7v/meX88awLOhGR3RiJSa6G3D eR5kmXy56QNB+FCD3MvWGs63exhuv9BxJp1yaaHAMLu5lvmWTkp3mJd7aHxs9MUCnhf3vz ajYFtGm0d3LGyR3TBEn4ofigIl+CkfpRY95pm8dxAaBkQzzoSXhgqhbUiQ3F7Q==
ARC-Authentication-Results: i=1; mail-out.ntp.dev; none
Received: from mail.develooper.com (10-41-3-5.mailserver-rspamd.mailserver.svc.cluster.local [10.41.3.5]) by mail-out.ntp.dev (Postfix) with ESMTP id 722A19F; Wed, 22 Jul 2026 12:24:03 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
From: Ask Bjørn Hansen <ask@develooper.com>
In-Reply-To: <93dd7fbc-294b-4ab1-bea6-e6fa9ba20f1f@pdmconsulting.net>
Date: Wed, 22 Jul 2026 14:23:48 +0200
Content-Transfer-Encoding: quoted-printable
X-MS-Reactions: disallow
Message-Id: <5674BDFE-772A-402D-93D3-7C27DC14230B@develooper.com>
References: <sarah.grant.ietf@gmail.com> <CAATxVg6ypG75dRXMySEs1JFSCjRZ_3wQ985U-7P3WRjBnBEgNw@mail.gmail.com> <20260720113007.9E45662003D@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <al4OJLpJCgUZX5wD@localhost> <81B0134C-1619-4765-BA21-B81DAD0D918D@gmail.com> <93dd7fbc-294b-4ab1-bea6-e6fa9ba20f1f@pdmconsulting.net>
To: Danny Mayer <mayer@pdmconsulting.net>
Message-ID-Hash: DGJMNBMEYTEKDLXOCDVSQFD7LJ5JMOE7
X-Message-ID-Hash: DGJMNBMEYTEKDLXOCDVSQFD7LJ5JMOE7
X-MailFrom: ask@develooper.com
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: Sarah Grant <sarah.grant.ietf@gmail.com>, Miroslav Lichvar <mlichvar@redhat.com>, Hal Murray <halmurray@sonic.net>, ntp@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Ntp] Re: NTPv5: Operational use case for server/node identification
List-Id: Network Time Protocol <ntp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/f5fDWtt-0fKBHGYU6N6xi7ABPP8>
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 Jul 21, 2026, at 02:39, Danny Mayer <mayer@pdmconsulting.net> wrote: > > The Extension Field contains the EF Id and the length of the extension field in bytes. The body of the extension field can be of any length but it is reasonable to limit the length of this one to something like 8 bytes or similar. 8 bytes is tight, that's only twice the refid. 255 bytes seems unnecessarily wasteful and would either invite amplification or need some complicated semantics for communicating truncation. I'd go with something between 32 and 64 bytes. Either one holds what an operator will realistically use: an opaque identifier[1] or a name for the site and node. With 48 or 64 you can have both. I'd also make it a fixed size field, zero padded, carried at the same size in the request. Request and response are then always the same size, so there's no amplification to argue about, nothing to truncate, and no length byte. Both sizes are a multiple of 4 with the header, so the NTPv4 restrictions are fine too. On whether "a Unicode string" is well defined: say UTF-8. NSID is opaque octets, which is why RFC 5001 makes user interfaces print it as hex even though operators put readable ASCII in there. Ask [1] a 128 bit identifier can fit as hex, base32, base58, depending on how much space you want for something else.
- [Ntp] NTPv5: Operational use case for server/node… Marco Davids (IETF)
- [Ntp] Re: NTPv5: Operational use case for server/… Daniel Franke
- [Ntp] Re: NTPv5: Operational use case for server/… Marco Davids (IETF)
- [Ntp] Re: NTPv5: Operational use case for server/… Steven Sommars
- [Ntp] Re: NTPv5: Operational use case for server/… Giovane C. M. Moura
- [Ntp] Re: NTPv5: Operational use case for server/… Steven Sommars
- [Ntp] Re: NTPv5: Operational use case for server/… Marco Davids (IETF)
- [Ntp] Re: NTPv5: Operational use case for server/… Giovane C. M. Moura
- [Ntp] Re: NTPv5: Operational use case for server/… Miroslav Lichvar
- [Ntp] Re: NTPv5: Operational use case for server/… Marco Davids (IETF)
- [Ntp] Re: NTPv5: Operational use case for server/… Miroslav Lichvar
- [Ntp] Re: NTPv5: Operational use case for server/… Marco Davids (IETF)
- [Ntp] Server identifier ID Extension Field Danny Mayer
- [Ntp] Re: Server identifier ID Extension Field Danny Mayer
- [Ntp] Re: Server identifier ID Extension Field Steven Sommars
- [Ntp] Re: Server identifier ID Extension Field Giovane C. M. Moura
- [Ntp] Re: Server identifier ID Extension Field Miroslav Lichvar
- [Ntp] Re: Server identifier ID Extension Field Giovane C. M. Moura
- [Ntp] Re: [EXT] [EXT] Re: Server identifier ID Ex… Windl, Ulrich
- [Ntp] Re: [EXT] [EXT] Re: Server identifier ID Ex… Danny Mayer
- [Ntp] Re: [EXT] [EXT] Server identifier ID Extens… Windl, Ulrich
- [Ntp] Re: [EXT] [EXT] Server identifier ID Extens… Danny Mayer
- [Ntp] Re: NTPv5: Operational use case for server/… Giovane C. M. Moura
- [Ntp] Re: [EXT] [EXT] NTPv5: Operational use case… Windl, Ulrich
- [Ntp] Re: [EXT] [EXT] NTPv5: Operational use case… Marco Davids (IETF)
- [Ntp] Re: NTPv5: Operational use case for server/… Hal Murray
- [Ntp] Re: NTPv5: Operational use case for server/… Miroslav Lichvar
- [Ntp] Re: NTPv5: Operational use case for server/… Sarah Grant
- [Ntp] Re: NTPv5: Operational use case for server/… Hal Murray
- [Ntp] Re: NTPv5: Operational use case for server/… Miroslav Lichvar
- [Ntp] Re: NTPv5: Operational use case for server/… Sarah Grant
- [Ntp] Re: NTPv5: Operational use case for server/… Danny Mayer
- [Ntp] Re: NTPv5: Operational use case for server/… Ask Bjørn Hansen
- [Ntp] Re: NTPv5: Operational use case for server/… Danny Mayer
- [Ntp] Re: NTPv5: Operational use case for server/… Miroslav Lichvar
- [Ntp] Re: NTPv5: Operational use case for server/… Danny Mayer
- [Ntp] Re: NTPv5: Operational use case for server/… Harlan Stenn
- [Ntp] Re: NTPv5: Operational use case for server/… Hal Murray
- [Ntp] Re: NTPv5: Operational use case for server/… Danny Mayer
- [Ntp] Re: [EXT] [EXT] Re: NTPv5: Operational use … Windl, Ulrich
- [Ntp] Re: [EXT] [EXT] Re: NTPv5: Operational use … Miroslav Lichvar
- [Ntp] Re: NTPv5: Operational use case for server/… Hal Murray
- [Ntp] Re: [EXT] [EXT] Re: NTPv5: Operational use … Windl, Ulrich
- [Ntp] Re: NTPv5: Operational use case for server/… Danny Mayer