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

Miroslav Lichvar <mlichvar@redhat.com> Thu, 18 August 2022 08:12 UTC

Return-Path: <mlichvar@redhat.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5398EC159527 for <ntp@ietfa.amsl.com>; Thu, 18 Aug 2022 01:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmOR7MFlAigK for <ntp@ietfa.amsl.com>; Thu, 18 Aug 2022 01:12:38 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694E6C152706 for <ntp@ietf.org>; Thu, 18 Aug 2022 01:11:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660810274; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2+in/zifvBJ1nr3RBi9L7S0sEYhOKPJ+MHoQsErqjyg=; b=YtccKHJZIjOzY4xowg/7DjrVXq2F9PIrhWX2KdAHw9DpAsteqKVzTxPyxeW6gGLRU7rIbw hZU9t/Jni0ldnpzlFJl8qfdO10agKBFIFqgn11fBapx6DS8irKZmSNmpcJfMl7lqrqgqic 6eaCt15/SOTXAhE/F47SeEkmHUl2VCA=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-296-Iw_yn-ihMqmy3xvXEh-VZA-1; Thu, 18 Aug 2022 04:11:11 -0400
X-MC-Unique: Iw_yn-ihMqmy3xvXEh-VZA-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A38EC80390C; Thu, 18 Aug 2022 08:11:10 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C269E1415125; Thu, 18 Aug 2022 08:11:08 +0000 (UTC)
Date: Thu, 18 Aug 2022 10:11:07 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Harlan Stenn <stenn@nwtime.org>
Cc: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "ntp@ietf.org" <ntp@ietf.org>, Heiko Gerstung <heiko.gerstung@meinberg.de>
Message-ID: <Yv30G3Pxwr8wiEtp@localhost>
References: <133C5633-E4D5-42AF-8215-E3FDE28C5BF9@meinberg.de> <4f833218-231f-8c47-e529-b3ba00f6554e@nwtime.org> <62FB5EDB020000A10004C5CD@gwsmtp.uni-regensburg.de> <a89aeba9-5e88-2214-634f-7a9a7106eec3@nwtime.org> <Yvt4C97N+I51c54v@localhost> <d4ff7203-1c7a-2c9b-ab27-5c5143253b7e@nwtime.org> <YvyqnxraeuxbGqNs@localhost> <3d6d3d96-09cf-1122-f866-f561e676ce0b@nwtime.org> <YvzsAxnyEoNCw8bI@localhost> <59d0ab10-8c50-a71d-8c74-a94bc012a251@nwtime.org>
MIME-Version: 1.0
In-Reply-To: <59d0ab10-8c50-a71d-8c74-a94bc012a251@nwtime.org>
X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Gx7hy2sghregTj73YH4i2U4lalk>
Subject: Re: [Ntp] Antw: [EXT] Re: Quick review of WGLC for status change for draft-ietf-ntp-update-registries
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2022 08:12:39 -0000

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.

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.

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.

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

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. 

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

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

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

> If so, that's 100% compatibility.

If you ignore packets with EFs, i.e. the only new feature of v4 as you
say.

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

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

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

-- 
Miroslav Lichvar