Subject: Re: [Ntp] Finding leap-seconds.list

From: "[email-masked]" <[email-masked]>
Date: Thu, 08 Nov 2018 09:43:33 +0300

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. 

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.

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

//tsg

Sent from my HTC, so please excuse any typos this keyboard sucks!

----- Reply message -----
From: "Steve Allen" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Warner Losh" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Martin Burnicki" <[email-masked]>, <[email-masked]>
Subject: [Ntp] Finding leap-seconds.list
Date: Thu, Nov 8, 2018 08:28

On Thu 2018-11-08T07:04:26+0300 [email-masked] 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                    <[email-masked]>              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

---

From: Steve Allen <[email-masked]>
Date: Wed, 7 Nov 2018 22:58:54 -0800

On Thu 2018-11-08T09:43:33+0300 [email-masked] hath writ:
> 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.

Good luck with that.  I expect no more compliance than when the
director of time at USNO who was co-responsible for suggesting that
the leap second was the solution to the problem then decided that he
would ignore CCIR Rec 460 and continue the USNO broadcast time signals
without leap seconds.

https://www.ucolick.org/~sla/leapsecs/leapincept.html

---

From: Warner Losh <[email-masked]>
Date: Thu, 8 Nov 2018 08:41:01 -0700

On Wed, Nov 7, 2018 at 11:43 PM [email-masked] <
[email-masked]> 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.
>

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

> Cc: "Warner Losh" <[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, <[email-masked]>, "Martin
> Burnicki" <[email-masked]>, <[email-masked]>