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 18.08.2022 um 13:23 in Nachricht
<[e-mail]>:
> On 8/18/2022 1:36 AM, Ulrich Windl wrote:
>>>>> 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.
> 
> I think I've said this before.
> 
> Because Dave treated the RFCs as "the best information at that moment in 
> the development of NTP".  NTP has continued to evolve, after the 
> publication of the RFCs.
> 
> The same was true for NTPv1, v2, and v3.
> 
> As I recall, Dave changed "jitter" to "dispersion" somewhere in there, too.
> 
> The goal of the NTP Project is to evolve and improve the quality of 
> synchronized network time.  The goal is NOT to slavishly implement an 
> outdated specification.
> 
> Now if enough people WANT a version of NTP that accurately and 
> faithfully implements the v4 RFC, that's certainly doable.
> 
> But our experience is that people want their clocks sync'd as well as 
> possible, so they want the improvements we make.
> 
>>> 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.
> 
> Yes.  From clock_jitter.  Which is maintained based on local 
> observations, not from data received from client packets.
> 
>> 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).
> 
> Yes, and:
> 
> - name changes are not a fatal problem, as I discussed in my emails
>    with Heiko.  If one really cares, one can detect and accommodate
>    these name changes.
> 
> - by observation, nobody has cared about this before now, to the
>    degree that any attempt has been made to codify this.
> 
> On this last part, how would one expect to standardize on the variable 
> names in the protocol document if the algorithms were in a separate 
> document?
> 
>> OK, it's easy to say the packet format is still the same, but does it really 
> help?
> 
> Does it hurt?
> 
> What is the goal?
> 
> Please compare the situation with NTPv[234] and those upgrades, with how 
> things will play out with the proposed v5.
> 
>>> 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?
> 
>  From what, v3 to v4?  Possibly.  But "different" can be the same, 
> better, or worse.
> 
> And if the behavior of the latest v4 code is no worse than (or in any 
> cases, better than) what is described in the RFCs, who cares?
> 
> If one wants exact 5905 behavior, one can certainly pour over the code 
> to find the instance of the code that will best give that to them.  To 
> date, NOBODY has asked for that.
> 
>>> 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.
> 
> Who is suggesting this?
> 
> The code implements "respond with the version we were sent".
> 
> If a v3 server gets a v4 query:
> 
> - If the v4 query contains an EF, the server will drop it
> - If the v4 query contains no EF, then
> - - if there is no authentication, the server will respond with
>      a packet identified with v4 and no authentication.  The client
>      should be fine.  This happened a LOT from 1997 thru 1999,
>      tapering off after that.
> - - if there is authentication and that failed, the packet would
>      dropped.  As expected.
> - - if there is authentication that passed, the server will
>      respond with a packet identified with v4 and (correct)
>      authentication.  All should be well, and this almost certainly
>      happened a LOT from 1997 thru 1999, tapering off after that.
>>> The only EFs that have been 0-day supported by v4 have been autokey EFs.

The more versions you support, the messier that code will be. Specifically if you want to disable support of a specific version such code is a maintenance nightmare. Thus I think having separate handlers for each version is the way to go.
Still those handlers can use common 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).
> 
> I don't understand.

Did you try?

...
> What I've seen on NTPv5 is "design by committee" and no code.

Design is not complete yet, so why do you expect code now?

...

>> The control protocol _is_ important for remote monitoring. I guess that is 
> why it was designed and implemented (even if "ad hoc").
> 
> I'm not sure I agree about the ad hoc part.  See my points above.

Formatting the text lines in the server (including line breaks) for the variable list was a bad idea.

> 
> Otherwise, I hear you.  And my points remain:
> 
> - it's mostly useful for monitoring local servers

Why "local"? Maybe "site".

> - nobody has bitten the bullet and made this easier to use.
> 
> And I don't see how the mode 6 plays in to the status of 
> draft-ietf-ntp-update-registries, unless it shows that the proposed 
> document does not address mode 6.
> 
...

Regards,
Ulrich