Re: [Ntp] Antw: [EXT] Re: Quick review of WGLC for status change for draft-ietf-ntp-update-registries

[Harlan Stenn <[e-mail]>]

On 8/18/2022 1:11 AM, Miroslav Lichvar wrote:
> On Wed, Aug 17, 2022 at 02:44:42PM -0700, Harlan Stenn wrote:
>> Sometimes I have trouble taking you seriously.
> 
> Imagine how others feel about you, and I don't mean just you
> personally, but the whole project you represent.

I'm not going to go there.

I will say that I've done my best to keep my comments technical.  I have 
asked technical questions, and have not received many technical answers.

I don't see that you have replied with technical details below.  But you 
have taken shots at me.

> You write a specification that says messages in newer versions are
> ignored, but your implementation intentionally doesn't follow that,
> refering to some design rules that are not written anywhere.

I:

- didn't write those specs.  But you seem to blame me for them.

- didn't show up on the project until late into the evolution of v3.
   But you seem to blame me for how the project has evolved.

- have also been working very closely with Dave Mills since probably
   around 1995.  I have evaluated and, when appropriate applied the
   vast majority of the externally provided patches to the codebase,
   starting around 1996.  I could go on and on about this, but to
   what end?

Why would ANYBODY believe that the RFCs contain complete and 
comprehensive information about NTP?

Yes, there are times the reference implementation has evolved beyond the 
RFCs.  When I have noticed these things and asked Dave about them, I 
almost always get the answer "The new behavior is within the latitude of 
the RFC", and Dave sometimes/rarely tells me "The new implementation is 
better than what we had before.  Somebody should update the RFCs."

Why would ANYBODY believe that the NTP RFCs that were finalized in 2005 
(RFC 5905) and 2007 (RFC 5906), and were based on the (v4) reference 
implementation that first saw the light of day in 1997, contain "better" 
information than the Reference Implementation that has been under 
continuous active improvement for 24 years' time?

> You say it's important to use the algorithms from the specification to
> have a specific impulse response, yet your implementation doesn't do
> that and has a much worse impulse response.

I see two points there.

Is it a "specific" impulse response, or a "defined" impulse response?

Are you saying that current ntpd has a worse (or worse overall) impulse 
response than what is described by 5905?

If we can agree on what's going on here I'm happy to discuss this 
further.  I'm also happy to get input from Dave on this.

> You specify an Autokey protocol, but your implementation intentionally
> uses a different format of the field type and you don't tell anyone.

As I have already said:

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.

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

So while we didn't make a big deal about it, it never seemed to be a big 
deal.  I recall that you and I discussed this many years ago.  Do you 
recall this?  Was a bug report ever opened about it?

If folks who only implement NTS use the framework described in 5906, is 
there any problem?

> Your relationship with IETF seems unhealthy. It's almost like you
> don't really want anyone to interoperate with you, or use a more
> advanced implementation.

That's one POV.

>> In v1 the 3rd word is Estimated Drift Rate.
>>
>> In v2 and beyond the 3rd word is Synch Dispersion.
> 
>> None of these values are used in the basic time calculations.
> 
> 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.

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.

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

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

>> And this change was made/codified over 33 years' ago.
> 
> It's still a good example showing that NTP didn't follow the design
> principles you are now trying to enforce.

We disagree then.

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?

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

>> Do you agree that a v4 packet without EFs is equivalent to a v3 packet?
> 
> Yes. If the client doesn't use any EFs, it could send it as v3 for
> better compatibility with old servers.

I think you have removed context here.

If there are no EFs, what is the difference between a v3 and a v4 
packet?  I mean, beyond the value in the version field?

What is the "better" compatibility?

Where are these old v3 servers?  How many are there?  What problems do 
they have getting v4 client requests?

>> If so, that's 100% compatibility.
> 
> If you ignore packets with EFs, i.e. the only new feature of v4 as you
> say.

"ignore"?

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

I think that you removed too much context here.  Are you suggesting that 
a v3 server should know to ignore EFs if it gets a v4 packet?

>>> 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?
> 
> It means that v4 is not compatible with v3, i.e. v3 servers should
> drop v4 requests.

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

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

I know we disagree about this, but I still haven't seen a valid 
technical reason for your position.

>>> 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.
> 
> The client starts with a v4 request to detect the v5 support on the
> server. It can use the v4 response for synchronization. There is no
> delay in setting the clock.
> 
> 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.

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

Or am I misremembering?

I'm really trying to have a technical discussion here.

>> And the v5 work that I have see is all about "rough consensus" and, to date,
>> nothing about "working code".
> 
> 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.

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