Re: Predictable Internet Time

Toerless Eckert <tte@cs.fau.de> Tue, 18 April 2017 23:21 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DF812946E for <ietf@ietfa.amsl.com>; Tue, 18 Apr 2017 16:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 6ZOc2EJlFrbU for <ietf@ietfa.amsl.com>; Tue, 18 Apr 2017 16:21:32 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C421314F7 for <ietf@ietf.org>; Tue, 18 Apr 2017 16:21:30 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2FFF158C4B2; Wed, 19 Apr 2017 01:21:27 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 14EABB0BD47; Wed, 19 Apr 2017 01:21:26 +0200 (CEST)
Date: Wed, 19 Apr 2017 01:21:26 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Nico Williams <nico@cryptonector.com>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, Paul Eggert <eggert@cs.ucla.edu>, IETF Discussion Mailing List <ietf@ietf.org>, Patrik F?ltstr?m <paf@frobbit.se>
Subject: Re: Predictable Internet Time
Message-ID: <20170418232126.GD5937@faui40p.informatik.uni-erlangen.de>
References: <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <CAMm+Lwi_jU6gjdtdM6a2n_9_89tUvWBNXxnMtSjTEA++h1D4Ew@mail.gmail.com> <e0a43370-751f-808c-3719-9716f9cd57d1@isi.edu> <B990A5A4-D62B-4E10-9FF7-7BA4377C0958@frobbit.se> <7bc1a350-549c-c649-81c6-bcd19cff36d7@cisco.com> <B2E6846E-F25B-4792-8E13-B5D898B67223@frobbit.se> <9f719b6a-f3c0-ef98-1636-86e84106e366@cisco.com> <16db07fe-acc5-d178-b56c-755c3cf70680@cs.ucla.edu> <CAMm+LwjQ_kaSBzcJhem5CbPLvMCAJRFnRpqJgu8SFTTQpt4bzQ@mail.gmail.com> <20170418222004.GB2856@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170418222004.GB2856@localhost>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/tJV6ih7fhEdt0raqLtbj3hfLfDY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2017 23:21:39 -0000

Nice!

Why not start to tackle the problem pragmatically before asking for standards
when its clearly a political issue.

a) RFC describing the problems developers and system deployments can face
  because of leap seconds.
b) And best current practices to get around those issues. Eg: Expect clock
  smear on Jan 1 == reduced accuracy of ~1. Unless OS or other trusted
  info source gives explicit indication: NO leap, no smear.
c) And finally a description of the worst open issues when b) is applied.
   Anything worse than labels on products "reduced functionality on Jan 1
   after a leap second" ?

Cheers
    Toerless

On Tue, Apr 18, 2017 at 05:20:06PM -0500, Nico Williams wrote:
> On Tue, Jan 03, 2017 at 05:34:11PM -0500, Phillip Hallam-Baker wrote:
> > As I said, I want 30-100 years lead time so I can bake the schedule into
> > devices and remove a trust dependency.
> 
> 30 years' lead time for leap seconds?  Can't be done.
> 
> Leap seconds depend on events such as earthquakes.
> 
> You can estimate their frequency, but you can't estimate when they'll be
> inserted.
> 
> Nico
> -- 

-- 
---
tte@cs.fau.de