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/19/2022 12:18 AM, Ulrich Windl wrote:
>>>> 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.

I think you're trying to put words into my mouth.

And the more I re-read your last sentence there, the worse you look to 
me.  Have you considered that your statements and POV might have more to 
say about you than they do about your target?

You also seem to be blaming me/us for not conveying 100% of whatever 
information might be important to somebody.

I believe we have responsibilities *to* others.  We do not have 
responsibility *for* others.

I do my best to avoid hiding information.  As several here will attest, 
I tend to get into trouble by conveying my perceptions of what is going on.

The NTP Project has always been open source, and has encouraged feedback 
and participation.

You may have heard me say (certainly in IETF NTP WG meetings) that "I am 
always happy to work with people of good character, who are competent 
and collaborative."

I do my very best to foster this sort of collaboration.

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

That seems disingenuous to me.

First, I'm not sure what you mean by "package format".  Next, the NTP 
Project's (open source) code has always been considered as a Reference 
Implementation.

One goal/purpose of a reference implementation is to provide "real 
working code" to help shed light in situations where the spec doesn't go 
far enough, or when somebody just wants to see one way to "get it done."

Next, for a very long time, there were very few alternate 
implementations.  And of those, NONE were offered as additional 
reference implementations.  Mostly because they only implemented the 
parts they cared about.

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

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

You're complaining about the displayed field size.

The value of clk_wander comes from the clock_stability variable, which 
is a double.

The bits are there, it's just that in the default format you're not 
seeing as many as you'd like.

>>
>> 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'm in no position to look at anything other than a small fraction of 
internet traffic.

But given everything I have seen and observed (including the lack of 
email or bug reports) on this matter and considering that the "lifetime" 
of NTPv1 ended sometime around November of 1989, I'm pretty comfortable 
with my statement.

To return the favor, how do you _know_ my position might be incorrect? 
Do you even _suspect_ it's incorrect?

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

They often do if something is broken and they want it to work...

And just like the v1 discussion above, the lifespan of v2 was from late 
1989 until June of 1993.

Perhaps somebody has some ancient email archives we can search for this.

Better yet, I can get you an ntp2 tarball and you can try it out and 
report back.

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

So please describe how this alleged {difference in POV that is not about 
a problem} is an actual problem.

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

If you want DES keys, you can enable them.

> Autokey is another: First promoted, then deprecated.

But can still be used.

Are you complaining that this isn't "set it once and forget it"?

You must be very frustrated if you drive a car.  All that speeding up, 
slowing down, making turns...

So how is this thread from you actually significant?

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

You're mischaracterizing what I said again.

Please stop it.

There is no implementation for me to criticize.  I am criticizing the 
discussions I am seeing.

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

Then take a guess.  I'll give you a hint: the only generally available 
use of EFs for NTPv4 is Autokey.  People have been talking about how 
Autokey is insecure and should not be used for something like 10 years' 
time now.

I suspect it was a TINY fraction of NTP traffic, even during the ~10 
year window that AUutokey was usable.

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

Feel free to implement this and make it available.

Better yet, spin up a 25 year old v3 server and point a v4 client at it, 
and a v4 server and point a v4 client at it, and see how well they each 
do.  Let us know what you learn.

>>
>> What you are advocating for is REDUCED service, for no good reason.
> 
> Sometimes denying a request can be preferable to serving the request badly.
> 
> ...

Sure.  But what about in this case?  Do you _know_ it's better in this 
case, or do you _suspect_ it?

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

We're back to your local policy choice, when the discussion is about 
mechanism and what folks SHOULD/MUST do.

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

Back at ya.  How many of your points above are hypothetical?

And how is what I wrote hypothetical?  Each NTP release has gone thru 
TONS of testing to make sure it behaves as-expected in a very wide 
variety of circumstances.  OK, I don't *know* this, but Dave has said it 
many times, and I have never had a reason to doubt his word.

As I said, if the v5 code gets even 10%  of the scrutiny ...

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

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