Subject: [Ntp] Re: NTPv5: Operational use case for server/node identification
From: Ask Bjørn Hansen <[email-masked]>
To: Danny Mayer <[email-masked]>
Cc: Sarah Grant <[email-masked]>, Miroslav Lichvar <[email-masked]>, Hal Murray <[email-masked]>, [email-masked]
Date: Wed, 22 Jul 2026 14:23:48 +0200
List-Id: Network Time Protocol <ntp.ietf.org>

> On Jul 21, 2026, at 02:39, Danny Mayer <[email-masked]> 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.