Re: [Ntp] Finding leap-seconds.list

Warner Losh <imp@bsdimp.com> Thu, 08 November 2018 15:41 UTC

Return-Path: <wlosh@bsdimp.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 B1E9D128BCC for <ntp@ietfa.amsl.com>; Thu, 8 Nov 2018 07:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bsdimp-com.20150623.gappssmtp.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 xz2iera4vgCr for <ntp@ietfa.amsl.com>; Thu, 8 Nov 2018 07:41:14 -0800 (PST)
Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 059F3124BAA for <ntp@ietf.org>; Thu, 8 Nov 2018 07:41:13 -0800 (PST)
Received: by mail-it1-x134.google.com with SMTP id r12-v6so2162129ita.3 for <ntp@ietf.org>; Thu, 08 Nov 2018 07:41:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t3ig2hSb3qNI4MmU/Pi3mWoNbzyq43i1ARs4TxeWCf4=; b=iSRfnHs5VPzOoE0tEFiKvSrRuCFcTTxQd+dijdmYSS2briFmwgyuhJYT5LJ1Ef6/kz ujTbl2oFIIXapySygzgRS8y6GabCJ7NscmT4tjZy0SYYfNOoamSg4A80dhJd4sk+73RL iG0aQb3kdYvcKMzuLaknXobV4V3HPYRRuk39QZCEzuzhVeHR/tMwz1vqkQGjIIhhKKNd v3lqgEqrSlUVItoF3qDtFAR8OZHp8qcapU5xNosP9wdvJbvn7/bYDGsaheqA+GFAuuj6 Ystjidm5EB3dJtn4EAKylWvAcTXXOxqODKhWHE7nFW5J9/2NQ0AiiYEwZUnZf1Yyangg d9fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t3ig2hSb3qNI4MmU/Pi3mWoNbzyq43i1ARs4TxeWCf4=; b=HFHaAO/VRmMWy99Eom/96K6olVQNDmA8/jcJUDxFv9oX8pygsLt++9WAFSJ/jhXL3C 8Hgz/45oEs0JoYlYjAFETG/xZIvStnn58FooJ+SuYy4sZAgaIpZh26Q+/1GDgL1lsEr+ XvqC8Wd4Z9is2mrEuZmtfkVGyNRIvS0QYggC/JJ7RsmaQu2UszfpHwv2Q2GaQ230yAXw xGGfdRz6CDaFFCpe6uF4DDOz/matHohEH9YTEaeGEfSRNrNXGHbX3DPYpbF2uMOARRpB P8CQ9vQsVIHxzvwsGcXOX2hiT19hz6mDEDMw/8I9nQ9eD81Nmd30h7uDn7vf1Rb3ibfY tRDg==
X-Gm-Message-State: AGRZ1gKasekfZXi1joME8jRAVbtj+e96vbpPY2/K88kx0Mm9oRka7uZf XqoJYQ/FxC3AC9DdbUEDZ9gb/QO3ETVjAC07KTo5LQ==
X-Google-Smtp-Source: AJdET5eelRiO1SA4lqE56A9Yy+dDc9Xd5WRkE6u/doCzR8Hs+SJ47u2d+WQqdFoNv8hlbNh9BnnGrHqAQLW4a8Xqi6w=
X-Received: by 2002:a24:eb0b:: with SMTP id h11-v6mr1505717itj.47.1541691673052; Thu, 08 Nov 2018 07:41:13 -0800 (PST)
MIME-Version: 1.0
References: <E1gKe2T-0007Ql-Nd@elasmtp-galgo.atl.sa.earthlink.net>
In-Reply-To: <E1gKe2T-0007Ql-Nd@elasmtp-galgo.atl.sa.earthlink.net>
From: Warner Losh <imp@bsdimp.com>
Date: Thu, 08 Nov 2018 08:41:01 -0700
Message-ID: <CANCZdfprqCLFiybdzeJkiw4J6v9Pc6FM07-DubQE+EASn3Us=A@mail.gmail.com>
To: Todd Glassey <tglassey@earthlink.net>
Cc: Steve Allen <sla@ucolick.org>, Thomas Peterson <hidinginthebbc@gmail.com>, ntp@ietf.org, eggert@cs.ucla.edu, dsibold.ietf@gmail.com, Martin Burnicki <martin.burnicki@meinberg.de>, denis.reilly@orolia.com
Content-Type: multipart/alternative; boundary="000000000000869c0e057a291047"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ClPptgyLajjt8gvW8huZSTvGkuE>
Subject: Re: [Ntp] Finding leap-seconds.list
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: Thu, 08 Nov 2018 15:41:18 -0000

On Wed, Nov 7, 2018 at 11:43 PM tglassey@earthlink.net <
tglassey@earthlink.net> wrote:

> The IETF has no legal authority to post any TZ data either. It by the way
> is controlled by three treaties including an international commerce one, an
> AML one, and another from the ATF realm.
>

So is it barred by treaty from providing the information? I don't see how
any of these treaties are relevant.


> But the key thing here is in the US the public timebase and all operations
> about it are tied to 15USC272 and its predecessor, 271.
>

But the key here is that the *DATABASE* is comprised of thousands of data
and what US agencies are supposed to and not supposed to provide is
irrelevant to the argument. The leap seconds are part of the time database,
just like knowing  that the first Saturday in November is the time shift in
the US.


> This isn't really arguable. What is arguable is whether NIST is going to
> do its job or not it claim that under 15USC260 it's the DOT/RITA who is
> responsible for this. Since NIST cannot operate any of the joint
> timekeeping agreements without this IMHO they are stuck with making the
> data available from a legal standpoint.
>

Again, since we're talking about a database, this is not an argument with
any merit. The entire database is comprised of data from many things that
should be provided elsewhere. What makes the leapsecond data unique? How is
it fundamentally different than the rest of the offset data in this
database? There's a time that the offset is valid, and an offset.
Fundamentally, that's no different than the other offset data. I fail to
see the relevance of the US law angle at all. There's nothing in US law
that precludes others from providing it. There's nothing in US law that
requires people to get this data from any source at all. There is US that
says so and so should provide it, but again, that's doesn't preclude others
from also providing it.


> Again this is something the gov. is responsible for IMHO and it should be
> a formal project of NIST ITS or the Calibration Services desk.
>
> By the way the legal damage from spoofing this table US huge. So it is
> what it is.
>

What's the damage? This is a time database provided on an as-is basis for
the purposes of allowing time datum to be exchanged and displayed in a
pleasing format to local users.

Warner


> //tsg
>
> Sent from my HTC, so please excuse any typos this keyboard sucks!
>
> ----- Reply message -----
> From: "Steve Allen" <sla@ucolick.org>
> To: "tglassey@earthlink.net" <tglassey@earthlink.net>
> Cc: "Warner Losh" <imp@bsdimp.com>, <hidinginthebbc@gmail.com>, <
> ntp@ietf.org>, <eggert@cs.ucla.edu>, <dsibold.ietf@gmail.com>, "Martin
> Burnicki" <martin.burnicki@meinberg.de>, <denis.reilly@orolia.com>
> Subject: [Ntp] Finding leap-seconds.list
> Date: Thu, Nov 8, 2018 08:28
>
> On Thu 2018-11-08T07:04:26+0300 tglassey@earthlink.net hath writ:
> > IETF nor any other non government agency ascribed with time keeping
> > should be cross posting the LSL.  It is created and is a requirement
> > of NIST (and other Government) related time services.
>
> IETF is not the authority for the recent time change in Morocco.
> IETF is not the authority for the recent time change in Metlakatla.
> Nor for any of the other data in IANA tzdb is IETF the authority.
>
> All of that data is painstakingly gathered by volunteers from a wide
> variety of uncooperative sources in order that it is possible to
> convert between internal system times and localized civil times.
>
> The leap seconds data are not different in any respect from all of the
> other data in the IANA tz database.  Those data are also needed to
> convert between internal system times and localized civil times.
>
> If the IETF is going to claim no authority for the leap second
> data then please justify the chain of authority for all of the
> rest of the IANA tzdb, or else delete all of that as well.
>
> --
> Steve Allen                    <sla@ucolick.org>              WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
> 1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
> Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m
>
>