[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 17.08.2022 um 23:44 in Nachricht
<[e-mail]>:
> Miroslav,
> 
> Sometimes I have trouble taking you seriously.
> 
> On 8/17/2022 6:24 AM, Miroslav Lichvar wrote:
>> On Wed, Aug 17, 2022 at 02:30:20AM -0700, Harlan Stenn wrote:
>>> I believe that's what has already been done.  For the timing modes:
>>>
>>> v2 to v3 changed a variable in the packet header.
>> 
>> So if a v2 server responded to v3 request with v2 data in v3 packet,
>> the client would get incorrect data?
> 
> There are slight differences in the data content between v2 and v3.
> 
> In v2 the 2nd word is Synch Distance and the 3rd word is Synch Dispersion.
> 
> In v3 and beyond the 2nd word is Root Delay and the 3rd word is Root 
> Dispersion.
> 
> None of these changes are operationally significant.

So why were the packet fields renamed then? I guess the algorithms to set them up did change, too.

> 
> Do you disagree?
> 
> And this change was made over 30 years' ago.
> 
>> I thought you said the idea was to add new fields if incompatible
>> changes are made.
>> 
>> In case you forgot, v2 was not compatible with v1 either.
> 
> Different.
> 
> In v1 the 3rd word is Estimated Drift Rate.
> 
> In v2 and beyond the 3rd word is Synch Dispersion.
> 
> OK, in v1 the 2nd word is Estimated Error and in v2 and beyond the 2nd 
> word is Synch Distance.
> 
> None of these values are used in the basic time calculations.

But "estimated error" is used to set the client's clock (via timex.h interface), right.

An of the "mode 6" side it's even more adventurous:
Some time "phase" became "offset", "error" became "noise", "freq" became "frequency" (with a different unit),
"rootdispersion" became "rootdisp", "noise" became "clk_jitter" (I guessed), "jitter" became "sys_jitter", "stability" became "clk_wander", "poll" became "tc". (Using mode 6 for monitoring is a real adventure, specifically as there is no (or little?) documentation on the variables being used).
OK, it's easy to say the packet format is still the same, but does it really help?

> 
> And this change was made/codified over 33 years' ago.
> 
>>> v3 to v4 added extension fields.
>> 
>> As Ulrich already explained, that works only for the v3-subset of the
>> protocol, i.e. the same is if the protocol number didn't change.
> 
> OK.  What's your point?
> 
> Do you agree that a v4 packet without EFs is equivalent to a v3 packet?

The packet yes, but won't the frequently cited "pulse response" be different?

> 
> If so, that's 100% compatibility.
> 
> What problem do you see?
> 
>> A v3 server is not able to respond to a v4 request containing
>> extension fields, even if it's authenticated with a symmetric key that
>> the server knows.
> 
> So what?

That means the client has to keep different implementations per protocol version, making the whole discussing a bit useless IMHO.
Just "chopping off the extras that were added later" doesn't really work.

> 
> The only EFs that have been 0-day supported by v4 have been autokey EFs.

What does that mean, "0-day supported"? You sent it out to the public, but then say nobody should use it as it is broken and there is not easy replacement? You can safely assume that those EFs will be "ghosting around" for years. I think the whole autokey stuff wasn't really ready for public; instead it was a kind of public beta test that was canceled soon.

> 
> If the v3 server authenticates with a symmetric key, there will be no 
> problem.
> 
> v3 *does not describe EFs*.
> 
> v3 went EOL in November of 1998.
> 
> Why would a v4 client decide to send an EF to a v3 server?

Because id does not have separate implementations for each protocol version?

> 
> Is what you describe a real problem?  If so, how significant is it?
> 
> I guess I'm really asking what your goal is.
> 
>>> As I have said many times, the design of the timing modes and the packet
>>> structure allows NTP to reply to packets of lesser, equal, or greater
>>> version numbers and "it just works".
>> 
>> No, it doesn't. You may think it works, but you just don't see the
>> whole picture.
> 
> Then please sufficiently describe the actual problem(s).
> 
>>> Your NTPv5 work is explicitly breaking that rule, and y'all are apparently
>>> only recently beginning to see some of the consequences of that choice.
>> 
>> That rule isn't written anywhere and as you just shown, it wasn't
>> followed anyway. Why should be v4->v5 be different?
> 
> Please support your claim that the changes in the past were 
> operationally significant.
> 
> Please show how your claim that what you have proposed for v5 changes 
> are similarly operationally (in)significant.
> 
>>> It's not clear to me what or how long it will take for a v5 client to detect
>>> and remediate an attempt to talk to a v4 server.
>> 
>> If you read the draft, you would know there is no additional delay.
> 
> So what delay is there?  I'm trying to avoid spending time slogging thru 
> a significant document to obtain a small piece of information.

Harlan, we all read a lot of documents over and over...

> 
> And the v5 work that I have see is all about "rough consensus" and, to 
> date, nothing about "working code".

I think that is how software should be done: First have a concept, them implement it, the revalidate the concept, maybe just to decide whether the concept has a flaw or the implementation of the concept. Possibly NTP developement worked the other direction in the past (first implement, then specify).
However if you want to promote different competing implementations the "design first" has clear advantages.

> 
>>> It's not clear to me what or how long it will take a v4 client to detect and
>>> remediate an attempt to get time from a v5 server that does not respond to
>>> the v4 request.
>> 
>> As was said multiple times, a v5-only server cannot respond to v4
>> requests. The same as a v4-only server following RFC5905 cannot
>> respond to a v3 request and the same as a v3-only server following
>> RFC1305 cannot respond to a v2 request.
> 
> That doesn't clearly answer my question.
> 
> This goes to "how easy will it be to deploy your proposed v5 solution".

Maybe a significant part of the NTPv5 specification should handle the "protocol gateway", i.e.: how to handle requests from older NTP versions and how to send requests to older NTP implementations. Thinking this is not a problem to care about is simply wrong. Specifically if an implemenewr just wants to implement the currenct version, the rest of the document does not have to be "polluted" with all the compatibility stuff.

> 
>>>>>> Are there any client implementations using the NTPv4 control mode?
>> 
>>> If that is, indeed, what you are asking, then no, I'm not aware of anything.
>>> But how does that matter?
>> 
>> It gives us an idea how important it is to have it specified.
> I think you removed too much context in there.
> 
> And I don't see the correlation between "client implementations using 
> the NTPv4 control mode" and "how important is it to specify the control 
> modes".

The control protocol _is_ important for remote monitoring. I guess that is why it was designed and implemented (even if "ad hoc").

Regards,
Ulrich