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

[Harlan Stenn <[e-mail]>]

On 8/8/2022 4:07 AM, Ulrich Windl wrote:
>>>> 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.

Please tell me more about how one announces public and/or private 
extensions.

Please tell me if your experimental playground is private or on the 
public internet.

Please tell me what you think will happen if an experimental field type 
becomes published (as experimental, informational, or standard) and then 
gets a different field type number.

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

I didn't see how you answered this 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.

I disagree.  The new numbers may still be assigned, but there's still 
the potential/likely mess with the old numbers.

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

In what way is that a useful response to my assertion?  I said, in 
effect, "old stuff persists".  Are you refuting my assertion?

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

No.

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

NTP is about defined response to an impulse.

Since chrony, by definition, does not use the algorithms and has a 
different impulse response behavior, then by definition it is not NTP.

And separating the protocol from the algorithms makes things worse, in 
my opinion.  The general class of users has NO IDEA about the impulse 
response and the 2nd and 3rd order effects of impulse response choices. 
  Splitting the protocol and algorithms just pushes the problem out to 
people who are arguably *less* capable of making these decisions.

Just look at POSIX and leap seconds for a similar example.

> (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?)

...

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