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

[Ulrich Windl <[e-mail]>]

>>> Harlan Stenn <[e-mail]> schrieb am 08.08.2022 um 12:35 in
Nachricht
<[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.

I'm afraid you miss the fact that a public server may use private extensions
(not announced publically).
(Very much like the "X-" email headers)
Having a experimental playground seems like a good idea, especially if you
keep out of the official number space then.

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

See above.

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

No: Once Standard, the experimental numbers will be re-assigned to "official"
ones.

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

If I could predict the future, I'd be a rich man...

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

Maybe that's the real reason for your objection?

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

Well, I'm also a chrony-sceptic personally, but I must admit that it works.
Unsure it uses or provides NTP by definition, however...

(Maybe NTPv5 specification should distinguish between the *definition* of a
protocol parameter and a specific *algorithm* to compute it.
It could be considered to be a bug in older NTP specifications.
For example the Linux PPS code uses different algorithms, mostly because the
reference code did not fit well into the infrastructure of the kernel.
Another thing is hardcoding the MAXWANDER: If some implementation can
auto-detect it, why not allow?)

> 
> 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!
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp