[Ntp] Antw: Re: 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 18.08.2022 um 12:14 in Nachricht
<[e-mail]>:
...
> 
> The code is/was open source.  MANY folks built it from source.

Harlan,

there are several points to comment on, but taking just this one above: What are you trying to say?
AFAIR Dave Mills had the final hands on all changes of the clock algorithms. It seems you try to say "the public" is responsible for any mess in the code.

> 
> The code was in active production use.
> 
> Changing the code would have caused interoperability problems with 
> deployed production (public) use.
> 
> Nobody else seems to have implemented full NTPv4, including autokey or 
> mode 6 (or mode 7).

Well, actually neither mode 6, not mode 7 were specified beyond the package format; I'm not even sure about mode 7.
So interoparability between implementations would have been very questionable.
BTW: I think mode 6 in NTPv5 needs the ability to switch formats, and I suggest to implement JSON, because it's a rather simple and compact format (as compared to XML for example). The the system should change from formatting texts in the server to formatting the text lines from JSON in the client. So eventually more narrow or wider terminals could be used, and parsing the results by a program could be made much more reliable.

...
>> So you are ok with the client getting different data in different
>> units than it expects, assuming it doesn't do anything important with
>> this it anyway.
> 
> "assuming it doesn't do anything important with" the data, yes.  By your 
> definition, nothing important is being done.

Well two different points of view.
While talking on units and mode 6: In NTPv4 the stability (clk_wander) is limited to microseconds (three fractional digits of milliceconds); for GPS-synced clocks that value is 95% of the time between 0 and 1.  The precision of the values is nowhere specified...

> 
> I have seen ZERO evidence of "real" v1 NTP packets traversing the net. 
> I *believe* (and this has yet to be disproven) that people are sending 
> v[234] packets with a version field that says "1".  That's not a v1 packet.

But how do you _know_? I guess you _suspect_.

> 
> I have seen ZERO reports or emails where folks have said "We're running 
> real ntpv2 and are trying to get time from v3 and/or v4 servers, and we 
> have a problem because the v3/v4 servers are replying with different 
> data in the 2nd and 3rd words of the packet."

I'm afraid people doing stupid things hardly ever admit in public that they do.

> 
> So how can you justify saying this incompatibility is "significant"?

I'm afraid this is not about a problem, but about a point of view...

...
> 
> Can you (or anybody else) show that the differences and evolution of NTP 
> over the initial and v1-v4 efforts resulted in ANY 
> significant/non-trivial upgrade or interoperability issues?

Actually there were many. For example NTPv4 not supporting DES keys any more.
Autokey is another: First promoted, then deprecated.

> 
> Please compare this with what you envision when the gazillion deployed 
> pre-v5 implementations try and get time from a v5 (only) server.

I think it's unfair to criticize an implementation that does not exist yet. Not even a specification exists.

...
> What % of v4 NTP packets on the internet (assuming that is the right 
> place to watch for this) use EFs?

I can remember times when you could query the Internet for NTP servers. Unfortunately there exist many servers that are not reachable publically. So it's a bit hard to guess what kind of packets are circulating globally.

...
> 
> No, it means that a v3 server will drop a v4 client request that has an 
> EF (even with a valid MAC).

A v3 server should drop any v4 request IMHO.

> 
> What you are advocating for is REDUCED service, for no good reason.

Sometimes denying a request can be preferable to serving the request badly.

...
>> When v5 is widely supported, the default can be changed to start with
>> v5 and maybe fall back to v4 if the server is not responding.
> 
> I recall your previous content described that v5 servers should just 
> drop v4.

I'd say: s/should/may/

> 
> Now you are saying that one should not implement a server that is solely v5.

See above.

...
>> If I showed you a working NTPv5 server and client, would that change
>> your mind?
> 
> I sure don't have the time to poke at it.  But if it got even 10% of the 
> scrutiny and effort that even ntpv4 got before it was turned in to a 
> Standard I'd be satisfied.

You are getting hypothetical, and I think that's not fair:
The efforts to get the code done is probably much more than looking at it.

Regards,
Ulrich

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