Re: [Ntp] Antw: Re: Antw: [EXT] Re: Quick review of WGLC for status change for draft‑ietf‑ntp‑update‑registries

[Harlan Stenn <[e-mail]>]

On 8/11/2022 4:16 AM, Miroslav Lichvar wrote:
> On Thu, Aug 11, 2022 at 03:43:54AM -0700, Harlan Stenn wrote:
>> The design is that the base packet for a given NTP protocol stays the same
>> for future protocol versions.  If new info is wanted, it is APPENDED to the
>> packet.  The easiest way to get new stuff there might be to use EFs, rather
>> than by changing the base packet format and size.
> 
> Maybe that was the original intention, but if it's not specified
> anywhere I don't think we should be prevented from making incompatible
> changes in the protocol.

TANSSAAFL.

We make our choices and live with the consequences.

>> If v5 comes along and makes the base packet larger, it should do so by
>> appending the new data after the v4 base packet boundary.  Looking at A.5.3
>> (fast_xmit()) in 5905, a v5 server would respond to a v5 client request with
>> a v5 packet that is the expected size.  But a v4 (or v3) server would
>> respond with a v5 version number in the header area with a base packet
>> length of (to use the above example) 40 bytes.  The originating system would
>> see it got a v5 response with a short length. That packet should be
>> perfectly usable (as a v4 response).
> 
> If you look at A.5.1 in RFC5905, you will see
> 
> 	if (r->version > VERSION /* or format error */)
> 		return;                 /* format error */
> 
> That is, an NTPv4 server is supposed to drop an NTPv5/6/7 request.

Yes, that was the original plan.  And since that time, Dave Mills (et 
al) decided that was a (needless) restriction that made upward 
compatibility harder.  So that restriction was removed from the code.

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!