[Ntp] Re: NTPv5: Operational use case for server/node identification

[Danny Mayer <[e-mail]>]

On 7/22/26 8:23 AM, Ask Bjørn Hansen wrote:
>
>> On Jul 21, 2026, at 02:39, Danny Mayer <[e-mail]> 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.

I agree with Ask Bjørn.

I think that the length field is too big. 64K is too large for an EF. If 
you make it a 12-bit field then it would max out at 4K which should be 
plenty. You can then reuse the extra 4 bits in the header for flags and 
use one of them to indicate "too small" and you can then put in the size 
you need.


>
> 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.