Message-ID: <b9298b6a-4f6c-42b3-a685-65bc0d66e15e@ntp.org>
Date: Mon, 20 Jul 2026 19:52:59 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Miroslav Lichvar <mlichvar=40redhat.com@dmarc.ietf.org>,
 Hal Murray <halmurray@sonic.net>
References: <sarah.grant.ietf@gmail.com>
 <CAATxVg6ypG75dRXMySEs1JFSCjRZ_3wQ985U-7P3WRjBnBEgNw@mail.gmail.com>
 <20260720113007.9E45662003D@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
 <al4OJLpJCgUZX5wD@localhost>
Content-Language: en-US
From: Harlan Stenn <stenn@ntp.org>
In-Reply-To: <al4OJLpJCgUZX5wD@localhost>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID-Hash: 62B5HFZ334ISQJOLA67GXYEHA6X3D5YS
CC: Sarah Grant <sarah.grant.ietf@gmail.com>, ntp@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BNtp=5D_Re=3A_NTPv5=3A_Operational_use_case_for_server/node_iden?=
 =?utf-8?q?tification?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ntp/2rNd1SH0VTmn70s5g2x02lNb3Us>

On 7/20/2026 5:01 AM, Miroslav Lichvar wrote:
> On Mon, Jul 20, 2026 at 04:30:07AM -0700, Hal Murray wrote:
>> I think we should continue the no-amplification in size policy.
> 
> +1

No-amplification should be a SHOULD, not a MUST.

H
--
> The document says the request EF length is 0, which is not a valid
> length in NTPv4/v5 as it must cover also the EF header.
> 
>> One way to do that is for the client's request to have unused space.
>>
>> Next, we need to know how much space the server needs and/or if the answer
>> fit in the space allocated.
>>
>> How about using the first byte of the answer as a size?  0 on the client
>> size means empty.  n on the server size tells you the actual length if it
>> is <= than the size of the field, or the actual size if the answer has
>> been truncated to fit.
> 
> If it needs to work in both NTPv4 and NTPv5, yes, that would make
> sense to me, assuming 255 bytes as the maximum length is sufficient.
> 
> If it was only for NTPv5 (which allows EF lengths not divisible by 4)
> the additional length field wouldn't be necessary. The client would
> know it got everything when the EF in the response is shorter than in
> the request.
> 
>> I think we should keep the overall packet size the same even if that
>> leaves empty space in the answer slot.  The idea is to avoid timing
>> asymmetry due to different packet lengths on the wire between request and
>> response..
> 
> In NTPv5 the padding EF could be used instead, but for NTPv4 with its
> special restrictions on EF lengths that wouldn't work.
> 

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