Re: [Ntp] NTPv5: big picture

Philip Prindeville <philipp@redfish-solutions.com> Mon, 04 January 2021 19:39 UTC

Return-Path: <philipp@redfish-solutions.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 CE6B53A0FF0 for <ntp@ietfa.amsl.com>; Mon, 4 Jan 2021 11:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWkHdzCI8UXY for <ntp@ietfa.amsl.com>; Mon, 4 Jan 2021 11:39:42 -0800 (PST)
Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [45.33.216.244]) (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 D42ED3A0FF2 for <ntp@ietf.org>; Mon, 4 Jan 2021 11:39:42 -0800 (PST)
Received: from [192.168.3.4] ([192.168.3.4]) (authenticated bits=0) by mail.redfish-solutions.com (8.16.1/8.16.1) with ESMTPSA id 104JdfqP348084 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Jan 2021 12:39:42 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Philip Prindeville <philipp@redfish-solutions.com>
In-Reply-To: <20210104151813.GB2992437@localhost>
Date: Mon, 04 Jan 2021 12:39:41 -0700
Cc: Hal Murray <hmurray@megapathdsl.net>, NTP WG <ntp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A05A663-2E81-4B82-973D-E01846EE5C9E@redfish-solutions.com>
References: <20210101025440.ECE3340605C@ip-64-139-1-69.sjc.megapath.net> <20210104151813.GB2992437@localhost>
To: Miroslav Lichvar <mlichvar@redhat.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
X-Scanned-By: MIMEDefang 2.84 on 192.168.1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/QfTXrR2dCi1OWQ7soI6B6Xkkmcw>
Subject: Re: [Ntp] NTPv5: big picture
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Mon, 04 Jan 2021 19:39:44 -0000

> On Jan 4, 2021, at 8:18 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> 
> NTP needs to support UTC and it needs to announce
> leap seconds before they happen. Forcing some servers or clients to
> implement an unreliable TAI clock on top of an UTC clock only to make
> NTP slightly simpler is not a good idea.


I don’t subscribe to this line of reasoning.  It sounds a lot like getting the camel’s nose under the tent for justifying why leap information needs to be part of the protocol.  It doesn’t.  It’s an ugly vestige that should be jettisoned.

If we used strictly monotonic timestamps, and had a well understood mechanism for mapping from that to any other required format out-of-band, that would be more than adequate: it would be ideal.

It would KISS the protocol, plus allow us to quickly adjust to new, updated mappings, without reconfiguring NTP servers or (worse) being required to push out a new release.

Personally I think zoneinfo is the ideal single-source of all authoritative information about leap seconds, and trying to “fix” the same problem in multiple, uncoordinated places if fraught with risk.

Also zoneinfo is very well maintained, regularly updated, and overseen by several appropriate standards bodies.

-Philip