Re: [Ntp] Finding leap-seconds.list

" tglassey@earthlink.net " <tglassey@earthlink.net> Fri, 09 November 2018 04:26 UTC

Return-Path: <tglassey@earthlink.net>
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 7BC651277BB for <ntp@ietfa.amsl.com>; Thu, 8 Nov 2018 20:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Level:
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=tglassey@earthlink.net header.d=earthlink.net
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 UNYB1QRsKmwe for <ntp@ietfa.amsl.com>; Thu, 8 Nov 2018 20:26:50 -0800 (PST)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (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 C413A127598 for <ntp@ietf.org>; Thu, 8 Nov 2018 20:26:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1541737609; bh=RgCkBhHKIYUy3TAjQLNaUALmK294ZsxRb0m3 BT+CQOI=; h=Received:To:From:Cc:Subject:Date:MIME-Version: Content-Type:Message-ID:X-ELNK-Trace:X-Originating-IP; b=JChOkZgAL 5JpNaQDA4SJYPZtLzDfCUkLZQCWnYR7sHK4tZZ7imlP6uGJJTYt1KE0MQ46vvHlTmVN 7Ci/mHPGa37+KLvh8JZ0HlWpbWfN9fZ0OJ3E1wRd6++QP1Xl4/MMvuI22CEwe5bSmVm WfTudnn5gOImuqsdoogX3zOhKPACvuCKMIUGOWDVxUZxL7RoHJlBHaisg+idqxh7UVj OKyfjIaVXL6FA2xis2AAj2bBMXTYZow73owU8UgcPwQNn896hqQHGpKo14uvxDafsDZ QIOX5/E11KulyRGl4CJcVVksK0ZRilzsfYbHiGZz25+c1fTR/aSqrUj39F3hfRRTQ==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=DpL/yMcOkwj/gZJLWglsVARxS8LLQLuoLAy6PRM5gDLK6xS6owvVlDg12I9bR5RkshFIgNviwkj2Rtpkxl/Ce1QUjZwSPwP57o+YBTYmnICXe2FixFRrcyZ5cjvLC/dt65inDQaLZasNHPt7z/y2Udoh8zQCEfj9cBjLvBTnjg6flH7Hi2+CZdDumabxBkmToL7AT2dx6MZ4ldiHFM7+xDoQIu1zb8bsJc8bUTWssiHOEEEXSZC1p+eHKEX1VPKK91tdDddMwaOkzD2fmrx3WchkHVO8PQ7ocNupdRU/9Y11w0M217GgiLEBwTiMC8K0A8S/I9GIYC/5+AYiIUaUFA==; h=Received:To:From:Cc:Subject:Date:MIME-Version:Content-Type:Message-ID:X-ELNK-Trace:X-Originating-IP;
Received: from [166.170.39.16] (helo=[10.109.195.161]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from <tglassey@earthlink.net>) id 1gKyNU-000BVE-VY; Thu, 08 Nov 2018 23:26:42 -0500
To: Warner Losh <imp@bsdimp.com>
From: "tglassey@earthlink.net" <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
Date: Fri, 09 Nov 2018 07:26:38 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_0_1541737598990"
Message-ID: <E1gKyNU-000BVE-VY@elasmtp-masked.atl.sa.earthlink.net>
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798f062983fab6e0044172cd0a4a98dadd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 166.170.39.16
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Dn704qg3_ovt5HisSxv8KkxCCmM>
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: Fri, 09 Nov 2018 04:26:53 -0000

Not barred but it creates a legal liability. The idea is that only authorized patties should be publishing it (officially).  The distros themselves pick up a liability their end user licensing doesn't cover since this is officially published information. 

As to the servers going down, yes of course but the way to deal with that is at the organization level through a formal complaint.
Sent from my HTC, so please excuse any typos this keyboard sucks!

----- Reply message -----
From: "Warner Losh" <imp@bsdimp.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>
Subject: [Ntp] Finding leap-seconds.list
Date: Thu, Nov 8, 2018 18:41

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