Re: [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 19.08.2022 um 11:14 in Nachricht
<[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.

So maybe explain your words that sound a bit like the oracle of Delphi to me:
---begin quote---
The code was written and deployed before 5906 was finished.

The code is/was open source.  MANY folks built it from source.

The code was in active production use.
---end quote---

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

I meant "packet" (in German there is only one word for both).

> Project's (open source) code has always been considered as a Reference 
> Implementation.

Yes, but at some point you'll have to decide whether the RFC or the implementation is the definitive reference.

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

I guess as long as the reference code is "good enough" there's no need for alternatives.

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

Whether it's "important" or not.

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

It's not just "displayed"; it's sent as ASCII string from the server that way!
I.e.: You cannot get a better resolution at the client side.

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

And is there a way to change the format other than changing the source and recompiling?
I guess: No

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

Well, we really cannot say where those VN==1 packets come from and why.

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

But when those packets are answered, it's not broken (in their opinion).

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

I didn't make it a problem; you did.

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

Yes, recompiling the sources.

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

Well, you'll have to referesh the certificates at least once per year, right?

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

Personal offense?

> 
> So how is this thread from you actually significant?

To you?

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

So what is "deployed" then?

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

The whole discussion was about not repeating mistakes made in the past.

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

Leave it at the admin level to decide.

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

Actually I won't argue any more on such.

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

Is the final quality really related to the amount of time spent in testing?
That's the basic question.

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