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

[Harlan Stenn <[e-mail]>]

On 8/8/2022 2:23 AM, Miroslav Lichvar wrote:
> On Mon, Aug 08, 2022 at 02:00:21AM -0700, Harlan Stenn wrote:
>> The problems I (and the NTP Project) have with this document include, but
>> are not limited to:
>>
>> - it uses far too many words to say far too little.  In other places it uses
>> far too few words to say even less, except where it says nothing about
>> various significant aspects of the registries.
> 
> Which significant aspects of the registries are you referring to?

I'll have to dig more for

While re-reading to find my answer, I note 4.3 says that Field Types 
from 0xF000 through 0XFFFF are reserved for experimentation and development.

This makes no sense to me.

If this experimental/development work is done "privately" then nobody 
cares what value is used.

If the work is done over the public internet, then something must be 
done to make sure different efforts do not use the same values.

Next, if this experimental/development work gets turned into a Standard, 
then implementations will likely need to support both the Standard and 
the experimental versions.  That's needless code bloat.

Given the large numbers of NTPv3 packets on the live internet, a full 22 
YEARS after ntp4 was released and work was halted on ntp3, I strongly 
question the need for this range to be reserved for experimentation and 
development.

I'll also point out that, as noted in draft-stenn-ntp-extension fields, 
a number of 0xFxFF values are being used for the I-DO extension field 
proposal, as documented in draft-stenn-ntp-i-do.

Also, as I'm more carefully reading the proposal, I find it curious that 
you are are not objecting to its citing of 5906. I recall that you have 
explicitly ignored that document when writing chrony, at least around 
the numeric range of keyIDs, because 5906 was "informational" and not 
listed as an optional Standard.

And now that I have finished my re-read of Section 4, I see that the 
places where I thought the original document used too many words are now 
gone.

But there is still no discussion about the V1 and V2 EF formats, or the 
description of how the Field Type is composed (which goes to my 22 years 
of conscious design specification).

>> - Table 1 is incomplete.  It does not include the value used by RFC 7821,
>> and it frequently refers to values that are "reserved for historic reasons"
>> without further explanation.  This leads me to:
> 
> The Checksum Complement EF (0x2005) is present in the table 1, but it
> is incorrectly described as "Reserved for historic reasons". That
> should be changed to refer to RFC 7821. Only the Autokey-related
> entries should be "Reserved for historic reasons".

I do not believe there is *any* reason that the V1 EF format values 
(assuming that is what the "Reserved for historic reasons" is referring 
to) cannot be used by the current/V2 handlers.

These values should still be documented, and the Autokey-related values 
in V2 format should be assigned in the V2 table.

>> - The document does not describe (ignores?) 22 years of conscious design
>> decisions around the two versions (revisions?) of extension field syntax,
>> which Dave Mills and I have previous spent 3+ years' time and effort (10
>> document revisions) in documenting, in draft-stenn-ntp-extension-fields.
> 
> As was discussed when the draft was submitted, it was making changes
> incompatible with RFC7822, e.g. decreasing the minimum EF length. We
> can do that in NTPv5, but not in NTPv4.

How does minimum EF length really apply here?

As we should all know, I strongly disagreed with the change in 7822 that 
(needlessly) increased the minimum EF length, but I was not aware of it 
in time to say so.  I have also demonstrably proven (ie, with working 
code) that the increase in minimum EF length is not needed.

Regardless, there is no conflict between 
draft-stenn-ntp-extension-fields and 7822.  If one wants compliance with 
7822, one simply uses an appropriate 0-filled EF structure, as allowed 
by draft-stenn-ntp-extension-fields.

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