Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)

Philip Prindeville <philipp@redfish-solutions.com> Tue, 05 January 2021 18:27 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 E29C73A10E5 for <ntp@ietfa.amsl.com>; Tue, 5 Jan 2021 10:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6YwKW3koIXEB for <ntp@ietfa.amsl.com>; Tue, 5 Jan 2021 10:27:57 -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 C3EA13A109B for <ntp@ietf.org>; Tue, 5 Jan 2021 10:27:57 -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 105IRtu9354007 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Jan 2021 11:27:55 -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: <ba5d2cde-6b5e-d9b6-1877-c4060bf43e80@rubidium.se>
Date: Tue, 05 Jan 2021 11:27:55 -0700
Cc: Miroslav Lichvar <mlichvar@redhat.com>, ntp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C761841F-F12A-4A8F-B9CD-61FEAB497CE1@redfish-solutions.com>
References: <20210102081603.1F63C40605C@ip-64-139-1-69.sjc.megapath.net> <cecaf661-92af-8b35-4c53-2f025c928144@rubidium.se> <20210104164449.GE2992437@localhost> <b1e61f7d-6cea-5e99-69f0-7eae815d9e19@rubidium.se> <20210105083328.GA3008666@localhost> <ba5d2cde-6b5e-d9b6-1877-c4060bf43e80@rubidium.se>
To: Magnus Danielson <magnus@rubidium.se>
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/5DaE-k0ntGGuS9sdw1PdZKp1gjs>
Subject: Re: [Ntp] CLOCK_TAI (was 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: Tue, 05 Jan 2021 18:27:59 -0000


> On Jan 5, 2021, at 7:10 AM, Magnus Danielson <magnus@rubidium.se> wrote:
> 
> Second challenge, if we have a TAI-like core format, and we indeed can
> rebuild a TAI replica, and we do not consider this enough, would a TAI
> format allows us to fairly cheaply adapt that to other formats? Turns
> out that this comes very cheap and is easy to do robust, if and only if,
> one has access to the TAI-UTC difference and information about an
> upcoming one as that eventually approaches.


Not to be banging the same drum, but… Zoneinfo has the necessary information.  People shouldn’t be operating hosts that aren’t getting regular updates if they’re on the Internet, because vulnerabilities aren’t being patched in that case.  Indeed, even hosts that aren’t on the internet should still be receiving patches: that’s just good hygiene.

So hosts are covered.

My concern is for embedded devices that require accurate time (video cameras, smart appliances, power and water meters, industrial instrumentation, etc.) not having such updates.

Maybe a separate protocol is required to handle Zoneinfo dissemination… or at least a relevant slice of it… delivered to IoT’s.  They don’t need the entire table: just for their timezone, and from now for as far forward as the table goes (or at least through the next transition/event).

Does anyone else see value to handling that orthogonally?

-Philip