Re: [art] Predictable Internet Time

Joe Touch <touch@isi.edu> Tue, 28 March 2017 19:42 UTC

Return-Path: <touch@isi.edu>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B84A129A07 for <art@ietfa.amsl.com>; Tue, 28 Mar 2017 12:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 fVK0U8Mzd2ku for <art@ietfa.amsl.com>; Tue, 28 Mar 2017 12:42:05 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A565E129573 for <art@ietf.org>; Tue, 28 Mar 2017 12:42:02 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2SJfgXE020547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 12:41:42 -0700 (PDT)
To: Nico Williams <nico@cryptonector.com>
References: <m1csrkh-0000GYC@stereo.hq.phicoh.net> <alpine.DEB.2.11.1703281603500.13590@grey.csi.cam.ac.uk> <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> <20170328190045.GG7490@localhost> <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> <20170328191914.GI7490@localhost>
Cc: Tony Finch <dot@dotat.at>, Philip Homburg <pch-ietf-art@u-1.phicoh.com>, art@ietf.org
From: Joe Touch <touch@isi.edu>
Message-ID: <470f9a23-ecbb-4c87-d96d-124690f05419@isi.edu>
Date: Tue, 28 Mar 2017 12:41:42 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170328191914.GI7490@localhost>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/nmm3XAEOTBT544YNk8KP7jk8o3I>
Subject: Re: [art] Predictable Internet Time
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 19:42:06 -0000


On 3/28/2017 12:19 PM, Nico Williams wrote:
> On Tue, Mar 28, 2017 at 12:07:38PM -0700, Joe Touch wrote:
>> On 3/28/2017 12:00 PM, Nico Williams wrote:
>>>> AFAICT, wouldn't specing Unix interfaces to the different times below be
>>>> out of scope for the IETF?
>>> Yes and no.
>>>
>>> First, the IETF has and does specify some APIs.  (BSD sockets bindings
>>> for IPv6, GSS-API, and various others.)
>> Only network APIs, AFAICT>
> Network protocols often depend on or relate to time, thus there's a
> nexus.
Mostly they depend on continuous time, which is already pointed out.

>
>>> Regardless, how could we address our time issues without specifying what
>>> amounts to.. type conversions? 
>> *our* time issues are mostly that we need to know the time frame being
>> used, and to appreciate that there's no single solution that can be used
>> to calculate intervals AND correspond to civil time that avoids the need
>> for constantly-updated external information. No closed system is
>> sufficient for that.
> If you can keep track of who needs time in what form...
>
> And if you can't... then what's the point of adding PIT?

I don't think there is. Managing time across systems requires some sort
of coordination, either to unify time units or entire time scales. Once
you recognize that, it's sufficient to use UTC + locale.

Joe