Re: [art] Predictable Internet Time

Nico Williams <nico@cryptonector.com> Tue, 28 March 2017 19:19 UTC

Return-Path: <nico@cryptonector.com>
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 59918129486 for <art@ietfa.amsl.com>; Tue, 28 Mar 2017 12:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 r_Amag59wJ5v for <art@ietfa.amsl.com>; Tue, 28 Mar 2017 12:19:19 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0301D12956C for <art@ietf.org>; Tue, 28 Mar 2017 12:19:19 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 566971406B1F; Tue, 28 Mar 2017 12:19:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=GKCr+takFV1C4b mhD0vsQdBa/fE=; b=IoF2tnGVCkw56Rup2V4lPN2HJOYrgilwOZBRsaogi5vm9T CyC7EKjqT0hyn56W3UTbYVsxocKq+dBCrNlzJOq5V1jPHxuua2oeKxZ/XPyGTRqz ync3vsvjR9pOQoqpi69qjhmUT+mBpePYt7WBk44nADRaDlml/YI6XrXN9d//o=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 96E311406B0A; Tue, 28 Mar 2017 12:19:17 -0700 (PDT)
Date: Tue, 28 Mar 2017 14:19:15 -0500
From: Nico Williams <nico@cryptonector.com>
To: Joe Touch <touch@isi.edu>
Cc: Tony Finch <dot@dotat.at>, Philip Homburg <pch-ietf-art@u-1.phicoh.com>, art@ietf.org
Message-ID: <20170328191914.GI7490@localhost>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/fDeHTLvT_MQ6Zb72Fq1trAtc14M>
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:19:21 -0000

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.

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

> > ...
> >
> > Obviously, for leap second smearing, besides an API there is also
> > behavior (smearing).
> 
> I sincerely hope we can stop referring to this nonstandard technique. We
> certainly cannot even consider standardizing a conversion (even if that
> were our purview) between time scales that include smearing until there
> are smearing standards.

Agreed.

> A key point in this doc is that smearing makes things horribly worse,
> not better in any way, except to delude users into thinking otherwise.

Agreed!

Nico
--