Re: [Ntp] Finding leap-seconds.list

[Warner Losh <[e-mail]>]

On Thu, Nov 8, 2018, 9:26 PM [e-mail] <[e-mail]
wrote:

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

What is the legal liability here, specifically? It sounds like a very
torturous arguement that's missing a specific lo egal citation that can be
confirmed or denied.

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

It's a part of the database. Deleting part of the database on a vague legal
theory is not sound engineering.

Warner

Sent from my HTC, so please excuse any typos this keyboard sucks!
>
> ----- Reply message -----
> From: "Warner Losh" <[e-mail]>
> To: "Todd Glassey" <[e-mail]>
> Cc: "Steve Allen" <[e-mail]>, "Thomas Peterson" <
> [e-mail]>, <[e-mail]>, <[e-mail]>, <
> [e-mail]>, "Martin Burnicki" <[e-mail]>,
> <[e-mail]>
> Subject: [Ntp] Finding leap-seconds.list
> Date: Thu, Nov 8, 2018 18:41
>
> On Wed, Nov 7, 2018 at 11:43 PM [e-mail] <[e-mail]> 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" <[e-mail]>
> > To: "[e-mail]" <[e-mail]>
> > Cc: "Warner Losh" <[e-mail]>, <[e-mail]>, <
> > [e-mail]>, <[e-mail]>, <[e-mail]>, "Martin
> > Burnicki" <[e-mail]>, <[e-mail]>
> > Subject: [Ntp] Finding leap-seconds.list
> > Date: Thu, Nov 8, 2018 08:28
> >
> > On Thu 2018-11-08T07:04:26+0300 [e-mail] 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                    <[e-mail]>              WGS-84 (GPS)
> > UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
> > 1156 High Street               Voice: [phone]         Lng -122.06015
> > Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m
> >
> >
>
>
>