Subject: [Ntp] Finding leap-seconds.list

From: Thomas Peterson <[email-masked]>
Date: Wed, 07 Nov 2018 16:24:57 +0000

As was discussed at the working group meeting at IETF 103 [0], I have decided to do some research on the leap-seconds.list file that the IETF appears to be hosting at https://www.ietf.org/timezones/data/leap-seconds.list, but for some participants of this working group appear unclear about.

Where is this referenced in an RFC or other IETF document?
I ran a search of “leap-seconds.list” across the spread of draft and RFC documents. No RFC that I have found makes direct reference. However, the current NTP BCP draft Section 4.6 [1] contains:

... SNIP ...

The IETF maintains a leap second list [[7]] for NTP users who are not
   receiving leap second information through an automatic source.

   Files are also available from other sources:

... SNIP ...

With [[7]] holding reference to the file hosted at, and a list of links to sources.

What else is www.ietf.org hosting of a similar nature?
This file alone is not the only thing hosted under www.ietf.org, in fact https://www.ietf.org/timezones/ directory listings show that all recent versions of the tzdb (including 2018g the most recent) which suggests a human maintaining the hosting of it, or automated process. Versions only go back to 2016. These files are also available over FTP [2].

How long have these files been hosted on www.ietf.org?
Internet archive's Wayback Machine [3] shows it appearing back in 2015.

Who is using the file?
ntpd does depend on it as was discussed at the WG meeting, [4]. FreeBSD [5] holds reference to it and users have reported issues when being unable to access it in the past. In addition, at least one library [6] make use of it outside of ntpd, however I don't believe this is heavily used or cause non-developers or system administrators any pain if it went missing.

Where else is this data hosted?
Mentioned in the draft NTP BCP referred above, NIST apparently also hosts the file [7] however at time of writing I'm unable to access it to verify it matches, in addition the US Naval Observatory hosts the file [8]. There was an email thread in 2016 [9] which discussed it, linking to these and other hosted versions. Many other FTP servers on the public internet appear to mirroring ftp.ietf.org which also includes this file and all of tzdb.

What have I not found?
How the hosting arrangement of tzdb on [ftp|www].ietf.org is managed - by whom, or what mailing list discussions or documents discussed its creation or maintenance. Nor have I found any information about how often the file is requested, however I'm sure a system administrator has that information somewhere.

I hope this email is a sufficient starting point for the discussion around the future hosting of this data by the IETF and would warmly encourage Paul Eggert [10] or anyone else with better memories (or Google-fu) to bring forward what they know.

Regards

[0] https://youtu.be/Qe9jhEAa4Wg?t=2735
[1] https://tools.ietf.org/html/draft-ietf-ntp-bcp-07#section-4.6
[2] ftp://ftp.ietf.org/iana-timezone/
[3] http://web.archive.org/web/*/https://www.ietf.org/timezones/data/leap-seconds.list
[4] https://support.ntp.org/bin/view/Support/ConfiguringNTP
[5] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213448
[6] https://www.npmjs.com/package/leap-seconds-list
[7] ftp://time.nist.gov/pub/leap-seconds.list
[8] ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list
[9] https://mailarchive.ietf.org/arch/browse/ntp/?gbt=1&index=BPA3_2BJMS-TXHxhwfrbOkV4Y38
[10] https://mm.icann.org/pipermail/tz/2015-January/021986.html

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 7 Nov 2018 18:59:42 +0100

> As was discussed at the working group meeting at IETF 103 [0], I have decided to do some research on the leap-seconds.list file that the IETF appears to be hosting at https://www.ietf.org/timezones…

During the IETF NTP WG session I posted a link in the chat which points
to a PDF I wrote some time ago:
https://www.meinbergglobal.com/download/burnicki/the_ntp_leap_second_file.pdf

There are several "original" versions of that file published by the
IERS, NIST, and USNO.

One of those original files (usually the version from NIST) is used to
update the TZDB records, and the original file is also included in the
TZDB distribution/tar ball, which is then unpacked and made available at
the IETF web site.

The problem here is that first an update of the original leap second
file appears, and only whenever the next TZDB version is released after
that the file appears on the IETF web site.

So for most users it's better to pick up a file from one of the original
sites.

> This file alone is not the only thing hosted under www.ietf.org, in fact https://www.ietf.org/timezones/ directory listings show that all recent versions of the tzdb (including 2018g the most recen…

Yes, and since the leap seconds file is part of the TZDB, it also
becomes available via the IETF web site.

> ntpd does depend on it as was discussed at the WG meeting, [4]. FreeBSD [5] holds reference to it and users have reported issues when being unable to access it in the past. In addition, at least on…

I'm sure the file *is* heavily used, but maybe not directly from the
IETF web site.

It's a good source to become aware of an upcoming leap second, and it's
a good source to be able to determine the current UTC/TAI offset, as
e.g. required when using PTP which uses TAI timestamps by default.

Anyway, I think the file is mostly used by NTP or PTP servers since for
most applications the information interesting for clients can be passed
via the individual protocols.

Regards,

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Denis Reilly <[email-masked]>
Date: Wed, 7 Nov 2018 19:17:49 +0000

Thomas and Martin,

On doing my own research into this for the BCP, I found that the Time Zone database maintenance procedures are documented in BCP 175 / RFC 6557.

However, after the discussion during the WG meeting, I think it's better to remove the mention of the leap second file hosted by the IETF in the BCP. As Martin notes, there are better places to get it.

--
Denis Reilly  |  Technical Lead  |  [email-masked]  (585)321-5837

-----Original Message-----
From: ntp <[email-masked]> On Behalf Of Martin Burnicki
Sent: Wednesday, November 07, 2018 1:00 PM
To: Thomas Peterson <[email-masked]>; [email-masked]
Cc: Paul Eggert <[email-masked]>
Subject: Re: [Ntp] Finding leap-seconds.list

> As was discussed at the working group meeting at IETF 103 [0], I have decided to do some research on the leap-seconds.list file that the IETF appears to be hosting at https://www.ietf.org/timezones…

During the IETF NTP WG session I posted a link in the chat which points to a PDF I wrote some time ago:
https://www.meinbergglobal.com/download/burnicki/the_ntp_leap_second_file.pdf

There are several "original" versions of that file published by the IERS, NIST, and USNO.

One of those original files (usually the version from NIST) is used to update the TZDB records, and the original file is also included in the TZDB distribution/tar ball, which is then unpacked and made available at the IETF web site.

The problem here is that first an update of the original leap second file appears, and only whenever the next TZDB version is released after that the file appears on the IETF web site.

So for most users it's better to pick up a file from one of the original sites.

> This file alone is not the only thing hosted under www.ietf.org, in fact https://www.ietf.org/timezones/ directory listings show that all recent versions of the tzdb (including 2018g the most recen…

Yes, and since the leap seconds file is part of the TZDB, it also becomes available via the IETF web site.

> ntpd does depend on it as was discussed at the WG meeting, [4]. FreeBSD [5] holds reference to it and users have reported issues when being unable to access it in the past. In addition, at least on…

I'm sure the file *is* heavily used, but maybe not directly from the IETF web site.

It's a good source to become aware of an upcoming leap second, and it's a good source to be able to determine the current UTC/TAI offset, as e.g. required when using PTP which uses TAI timestamps by default.

Anyway, I think the file is mostly used by NTP or PTP servers since for most applications the information interesting for clients can be passed via the individual protocols.

Regards,

Martin
--
Martin Burnicki

Senior Software Engineer

Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp
ATTENTION: This email came from an external source.
Do not open attachments or click on links from unknown senders or unexpected emails.

---

From: Hal Murray <[email-masked]>
Date: Wed, 07 Nov 2018 12:38:20 -0800

[email-masked] said:
> However, after the discussion during the WG meeting, I think it's better to
> remove the mention of the leap second file hosted by the IETF in the BCP. As
> Martin notes, there are better places to get it. 

"Better" is an interesting word.  Better for who?

I think the key idea is that distros should include the leap-seconds file as 
part of their redistribution of the time zone data so that individual systems 
don't need to run a cron job to fetch it from someplace.

-- 
These are my opinions.  I hate spam.

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 7 Nov 2018 21:55:15 +0100

> don't need to run a cron job to fetch it from someplace.

At least in Debian it's part of tzdata that provides time zone
information. The location is /usr/share/zoneinfo/leap-seconds.list

The source of that is downloaded from iana:
https://www.iana.org/time-zones
ftp://ftp.iana.org/tz

Kurt

---

From: "Dieter Sibold" <[email-masked]>
Date: Thu, 08 Nov 2018 08:28:15 +0700

On 8 Nov 2018, at 2:17, Denis Reilly wrote:

> Thomas and Martin,
>
> On doing my own research into this for the BCP, I found that the Time 
> Zone database maintenance procedures are documented in BCP 175 / RFC 
> 6557.
>
> However, after the discussion during the WG meeting, I think it's 
> better to remove the mention of the leap second file hosted by the 
> IETF in the BCP. As Martin notes, there are better places to get it.
I agree with Denis.

>> As was discussed at the working group meeting at IETF 103 [0], I have 
>> decided to do some research on the leap-seconds.list file that the 
>> IETF appears to be hosting at 
>> https://www.ietf.org/timezones/data/leap-seconds.list, but for some 
>> participants of this working group appear unclear about.
>
> TZDB distribution/tar ball, which is then unpacked and made available 
> at the IETF web site.
>
> file appears, and only whenever the next TZDB version is released 
> after that the file appears on the IETF web site.
>
>> I ran a search of “leap-seconds.list” across the spread of draft 
>> and RFC documents. No RFC that I have found makes direct reference. 
>> However, the current NTP BCP draft Section 4.6 [1] contains:
>>
>> ... SNIP ...
>>
>> This file alone is not the only thing hosted under www.ietf.org, in 
>> fact https://www.ietf.org/timezones/ directory listings show that all 
>> recent versions of the tzdb (including 2018g the most recent) which 
>> suggests a human maintaining the hosting of it, or automated process. 
>> Versions only go back to 2016. These files are also available over 
>> FTP [2].
>>
>
>> ntpd does depend on it as was discussed at the WG meeting, [4]. 
>> FreeBSD [5] holds reference to it and users have reported issues when 
>> being unable to access it in the past. In addition, at least one 
>> library [6] make use of it outside of ntpd, however I don't believe 
>> this is heavily used or cause non-developers or system administrators 
>> any pain if it went missing.
>
> It's a good source to become aware of an upcoming leap second, and 
> it's a good source to be able to determine the current UTC/TAI offset, 
> as e.g. required when using PTP which uses TAI timestamps by default.
>
> Anyway, I think the file is mostly used by NTP or PTP servers since 
> for most applications the information interesting for clients can be 
> passed via the individual protocols.
>
>
> Regards,
>
> Martin
> --
> Martin Burnicki
>
> Senior Software Engineer
>
> Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 
> 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner 
> Meinberg, Andre Hartmann, Heiko Gerstung

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 8 Nov 2018 02:49:06 +0000

I propose the following occurs if the working group agrees:

* draft-ietf-ntp-bcp is updated to remove reference to the IETF hosted 
leap second file (as has already been suggested)
* The IETF ceases to host unpacked versions of tzdb
* Updates sent to various other mailing lists that may be affected by 
this change (off the top of my head, [email-masked], [email-masked], 
[email-masked]) as a matter of courtesy before its 
hosting is removed.

Regards

On 08/11/2018 01:28, Dieter Sibold wrote:
>>> As was discussed at the working group meeting at IETF 103 [0], I 
>>> have decided to do some research on the leap-seconds.list file that 
>>> the IETF appears to be hosting at 
>> One of those original files (usually the version from NIST) is used 
>> to update the TZDB records, and the original file is also included in 
>> the TZDB distribution/tar ball, which is then unpacked and made 
>> available at the IETF web site.
>>
>>> I ran a search of “leap-seconds.list” across the spread of draft and 
>>> RFC documents. No RFC that I have found makes direct reference. 
>>> fact https://www.ietf.org/timezones/ directory listings show that 
>>> all recent versions of the tzdb (including 2018g the most recent) 
>>> which suggests a human maintaining the hosting of it, or automated 
>>> process. Versions only go back to 2016. These files are also 
>>> available over FTP [2].
>>>
>>
>>> FreeBSD [5] holds reference to it and users have reported issues 
>>> when being unable to access it in the past. In addition, at least 
>>> one library [6] make use of it outside of ntpd, however I don't 
>>> believe this is heavily used or cause non-developers or system 
>>> administrators any pain if it went missing.
>>
>> it's a good source to be able to determine the current UTC/TAI 
>> offset, as e.g. required when using PTP which uses TAI timestamps by 
>> default.
>>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Nov 2018 02:51:02 +0000

>I propose the following occurs if the working group agrees:

+1

---

From: Warner Losh <[email-masked]>
Date: Wed, 7 Nov 2018 19:56:47 -0700

On Wed, Nov 7, 2018 at 7:49 PM Thomas Peterson <[email-masked]>
wrote:

> * Updates sent to various other mailing lists that may be affected by this
> change (off the top of my head, [email-masked], [email-masked],

So what's the new place to get it if the IEFT stops hosting it? All the
'much better places' don't earlier in the thread do not resolve for me at
all (or resolved to web pages that aren't suitable for automatic
downloading). The ntp leapsecond file has a format that's been fixed for at
least two decades. So what's the real 'next step' for people that download
it outside of the TZ stuff?

This is a very disruptive change to the FreeBSD community, at least. It's
not clear what it accomplishes.

Warner

> On doing my own research into this for the BCP, I found that the Time Zone
> database maintenance procedures are documented in BCP 175 / RFC 6557.
>
> However, after the discussion during the WG meeting, I think it's better
> to remove the mention of the leap second file hosted by the IETF in the
> BCP. As Martin notes, there are better places to get it.
>
> I agree with Denis.
>
>
> --
> From: ntp <[email-masked]> <[email-masked]> On Behalf Of
> Martin Burnicki
> To: Thomas Peterson <[email-masked]> <[email-masked]>;
> [email-masked]
> Cc: Paul Eggert <[email-masked]> <[email-masked]>
> decided to do some research on the leap-seconds.list file that the IETF
> appears to be hosting at
> update the TZDB records, and the original file is also included in the TZDB
> distribution/tar ball, which is then unpacked and made available at the
> IETF web site.
>
> The problem here is that first an update of the original leap second file
> appears, and only whenever the next TZDB version is released after that the
> file appears on the IETF web site.
>
> I ran a search of “leap-seconds.list” across the spread of draft and RFC
> documents. No RFC that I have found makes direct reference. However, the
> current NTP BCP draft Section 4.6 [1] contains:
>
> ... SNIP ...
>
> This file alone is not the only thing hosted under www.ietf.org, in fact
> https://www.ietf.org/timezones/ directory listings show that all recent
> versions of the tzdb (including 2018g the most recent) which suggests a
> human maintaining the hosting of it, or automated process. Versions only go
> back to 2016. These files are also available over FTP [2].
>
>
> ntpd does depend on it as was discussed at the WG meeting, [4]. FreeBSD
> [5] holds reference to it and users have reported issues when being unable
> to access it in the past. In addition, at least one library [6] make use of
> it outside of ntpd, however I don't believe this is heavily used or cause
> non-developers or system administrators any pain if it went missing.
>
>
> It's a good source to become aware of an upcoming leap second, and it's a
> good source to be able to determine the current UTC/TAI offset, as e.g.
> required when using PTP which uses TAI timestamps by default.
>
> most applications the information interesting for clients can be passed via
> the individual protocols.
>
>
> Regards,
>
> Martin
> --
> Martin Burnicki
>
> Senior Software Engineer
>
> Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre
> Hartmann, Heiko Gerstung

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 8 Nov 2018 03:13:25 +0000

As I have said in my starting email to this thread [0], this file is 
hosted in many places to which the IETF is not an authoritive source and 
from my end. I have experienced issues reaching the NIST host, however 
USNO's FTP server [1] appears to work for me.

Furthermore, leap-seconds.list is also packaged inside of FreeBSD itself 
[1] surely it would be more appropriate to reference this file instead 
of having the ntp service attempt to download it from a non-authoritive 
source on the internet, where it can fall under the same vendor software 
updates as all other critical files?

Regards

[0] https://mailarchive.ietf.org/arch/msg/ntp/COKDJAEBD5rsy5uOvHyO6QdXvN8

[1] ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list

[2] 
https://svnweb.freebsd.org/base/head/contrib/tzdata/leap-seconds.list?view=log

On 08/11/2018 02:56, Warner Losh wrote:
>
>
> On Wed, Nov 7, 2018 at 7:49 PM Thomas Peterson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     * draft-ietf-ntp-bcp is updated to remove reference to the IETF
>     hosted leap second file (as has already been suggested)
>     * Updates sent to various other mailing lists that may be affected
>     by this change (off the top of my head, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>) as a matter of courtesy
>     before its hosting is removed.
>
>
> So what's the new place to get it if the IEFT stops hosting it? All 
> the 'much better places' don't earlier in the thread do not resolve 
> for me at all (or resolved to web pages that aren't suitable for 
> automatic downloading). The ntp leapsecond file has a format that's 
> been fixed for at least two decades. So what's the real 'next step' 
> for people that download it outside of the TZ stuff?
>
> This is a very disruptive change to the FreeBSD community, at least. 
> It's not clear what it accomplishes.
>
> Warner
>
>
>     Regards
>
>
>>>     On doing my own research into this for the BCP, I found that the
>>>     Time Zone database maintenance procedures are documented in BCP
>>>     175 / RFC 6557.
>>>
>>>     However, after the discussion during the WG meeting, I think
>>>     it's better to remove the mention of the leap second file hosted
>>>     by the IETF in the BCP. As Martin notes, there are better places
>>>     to get it.
>>     I agree with Denis.
>>
>>>
>>>     -- 
>>>     Denis Reilly  |  Technical Lead  | [email-masked]
>>>     <mailto:[email-masked]> (585)321-5837
>>>
>>>     From: ntp <[email-masked]> <mailto:[email-masked]>
>>>     On Behalf Of Martin Burnicki
>>>     To: Thomas Peterson <[email-masked]>
>>>     <mailto:[email-masked]>; [email-masked]
>>>     <mailto:[email-masked]>
>>>     Cc: Paul Eggert <[email-masked]> <mailto:[email-masked]>
>>>>     As was discussed at the working group meeting at IETF 103 [0],
>>>>     I have decided to do some research on the leap-seconds.list
>>>>     file that the IETF appears to be hosting at
>>>>     https://www.ietf.org/timezones/data/leap-seconds.list, but for
>>>>     some participants of this working group appear unclear about.
>>>
>>>     One of those original files (usually the version from NIST) is
>>>     used to update the TZDB records, and the original file is also
>>>     included in the TZDB distribution/tar ball, which is then
>>>     unpacked and made available at the IETF web site.
>>>
>>>     The problem here is that first an update of the original leap
>>>     second file appears, and only whenever the next TZDB version is
>>>     released after that the file appears on the IETF web site.
>>>
>>>>     I ran a search of “leap-seconds.list” across the spread of
>>>>     draft and RFC documents. No RFC that I have found makes direct
>>>>     reference. However, the current NTP BCP draft Section 4.6 [1]
>>>>     contains:
>>>>
>>>>     ... SNIP ...
>>>>
>>>>     What else is www.ietf.org <http://www.ietf.org> hosting of a
>>>>     similar nature?
>>>>     This file alone is not the only thing hosted under www.ietf.org
>>>>     <http://www.ietf.org>, in fact https://www.ietf.org/timezones/
>>>>     directory listings show that all recent versions of the tzdb
>>>>     (including 2018g the most recent) which suggests a human
>>>>     maintaining the hosting of it, or automated process. Versions
>>>>     only go back to 2016. These files are also available over FTP [2].
>>>>
>>>
>>>     Yes, and since the leap seconds file is part of the TZDB, it
>>>     also becomes available via the IETF web site.
>>>
>>>>     How long have these files been hosted on www.ietf.org
>>>>     <http://www.ietf.org>?
>>>>     FreeBSD [5] holds reference to it and users have reported
>>>>     issues when being unable to access it in the past. In addition,
>>>>     at least one library [6] make use of it outside of ntpd,
>>>>     however I don't believe this is heavily used or cause
>>>     It's a good source to become aware of an upcoming leap second,
>>>     and it's a good source to be able to determine the current
>>>     UTC/TAI offset, as e.g. required when using PTP which uses TAI
>>>     timestamps by default.
>>>
>>>     Anyway, I think the file is mostly used by NTP or PTP servers
>>>     since for most applications the information interesting for
>>>     clients can be passed via the individual protocols.
>>>
>>>
>>>     Regards,
>>>
>>>     Martin
>>>     -- 
>>>     Martin Burnicki
>>>
>>>     Senior Software Engineer
>>>
>>>     <mailto:[email-masked]>
>>>     Phone: +49 5281 9309-414
>>>     Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover
>>>     17HRA 100322 Geschäftsführer/Managing Directors: Günter
>>>     Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung
>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Warner Losh <[email-masked]>
Date: Wed, 7 Nov 2018 20:25:36 -0700

> USNO's FTP server [1] appears to work for me.

Right, and have you researched USNO's file? Did you know there's subtle
differences between that file and that NIST file? In the past, it has not
been updated in a timely manner, and it's expiration date has been
unreliable. It's the whole reason FreeBSD doesn't use it: it only kinda
sorta looks like the right file. Also, non-military users aren't really
supposed to use this source because USNO's charter is to provide support to
the military.

> updates as all other critical files?

This points to a larger problem: There is no authoritative, authenticated
file that has this information.  Why should anybody trust the FreeBSD
project to say that something is authoritative? At least the NIST file is
nominally from an authoritative place (NIST in the US is the source of
time, and the file comes from their official services there). USNO's file,
when it hasn't skimped on the details, is also an authoritative file
provided by USNO to military users. So I don't think your assertion that
this is 'non-authoritative' is supported by history or the roles of NIST or
USNO to the time community. NIST and USNO have been providing these files
for at least two decades that I'm personally aware of. These files are
cryptographically checksummed, but not cryptographically signed.

The file that's in FreeBSD isn't the one used for ntpd because it goes
stale too quickly. FreeBSD does not necessarily need up to date timezone
information to properly function with the current separation of roles.
Requiring it to get the files via the timezone database updates to get
leapseconds, which are not a time-zone, is inverting the properly designed
dependency graph.

Surely it would be more appropriate to learn the history here rather than
shooting from the hip and being gratuitously insulting when an issue is
raised, but maybe I'm reading too much condescension into your statements.
Regardless, it's not helpful to having a civil conversation about it.

Warner

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Nov 2018 03:30:15 +0000

*   This points to a larger problem: There is no authoritative, authenticated file that has this information.

I am sure that this is true.  But the IETF explicitly stating that it is *not* going to be such a source, by removing a file from our website, is still a good thing.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 8 Nov 2018 10:31:08 +0700

Agree as well. 

Jared Mauch

> On Nov 8, 2018, at 9:51 AM, Salz, Rich <[email-masked]> wrote:
>

---

From: Warner Losh <[email-masked]>
Date: Wed, 7 Nov 2018 20:40:18 -0700

On Wed, Nov 7, 2018 at 8:30 PM Salz, Rich <[email-masked]> wrote:

>
>    - This points to a larger problem: There is no authoritative,
>    authenticated file that has this information.
>
>
>
> I am sure that this is true.  But the IETF explicitly stating that it is *
> *not** going to be such a source, by removing a file from our website, is
> still a good thing.
>

That's fine. The IETF can do what it sees fit. What's the timeline for
this. As I said, this is going to be a big PITA for thousands of systems
deployed that currently have this dependency. Up until now, there's been no
indication this is a problem and I need some information to formulate a
migration plan for all these users.

Warner

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 8 Nov 2018 03:58:36 +0000

Myself and others do not believe it is the IETF's responsibility to host 
this data as no published RFC is dependant on it, and far more 
authoritive sources already provide the data. To answer a question you 
posted to a different part of the thread, I do not believe we have 
consensus that it be removed, let alone have a date of its possible 
removal. If there is a suitable timeline that would help FreeBSD migrate 
its users please inform the list. One of my suggested actions was to 
discuss with potential affected mailing lists as a matter of courtesy so 
we minimise issues.

Finally, I apologise if you believe I was speaking in an insulting or 
condescending manner. It is absolutely not my intention to do so, I am 
just trying to keep my own facts straight.

Regards

On 08/11/2018 03:25, Warner Losh wrote:
>
> On Wed, Nov 7, 2018 at 8:13 PM Thomas Peterson 
> Right, and have you researched USNO's file? Did you know there's 
> subtle differences between that file and that NIST file? In the past, 
> it has not been updated in a timely manner, and it's expiration date 
> has been unreliable. It's the whole reason FreeBSD doesn't use it: it 
> only kinda sorta looks like the right file. Also, non-military users 
> aren't really supposed to use this source because USNO's charter is to 
> provide support to the military.
>
> This points to a larger problem: There is no authoritative, 
> authenticated file that has this information.  Why should anybody 
> trust the FreeBSD project to say that something is authoritative? At 
> least the NIST file is nominally from an authoritative place (NIST in 
> the US is the source of time, and the file comes from their official 
> services there). USNO's file, when it hasn't skimped on the details, 
> is also an authoritative file provided by USNO to military users. So I 
> don't think your assertion that this is 'non-authoritative' is 
> supported by history or the roles of NIST or USNO to the time 
> community. NIST and USNO have been providing these files for at least 
> two decades that I'm personally aware of. These files are 
> stale too quickly. FreeBSD does not necessarily need up to date 
> timezone information to properly function with the current separation 
> of roles. Requiring it to get the files via the timezone database 
> updates to get leapseconds, which are not a time-zone, is inverting 
> the properly designed dependency graph.
>
> Surely it would be more appropriate to learn the history here rather 
> than shooting from the hip and being gratuitously insulting when an 
> issue is raised, but maybe I'm reading too much condescension into 
> your statements. Regardless, it's not helpful to having a civil 
> conversation about it.
>
> Warner
>
>     Regards
>
>
>     [0]
>     https://mailarchive.ietf.org/arch/msg/ntp/COKDJAEBD5rsy5uOvHyO6QdXvN8
>
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>,
>     [email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>,
>     [email-masked]
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked]
>     <mailto:[email-masked]>>) as a matter of courtesy
>     <mailto:[email-masked]>
>     >>>     <mailto:[email-masked]
>     <mailto:[email-masked]>> (585)321-5837
>     >>>
>     >>>     From: ntp <[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>>     To: Thomas Peterson <[email-masked]
>     <mailto:[email-masked]>>
>     >>>     <mailto:[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     >>>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>>     Cc: Paul Eggert <[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>>     During the IETF NTP WG session I posted a link in the chat
>     which
>     >>>     points to a PDF I wrote some time ago:
>     >>>
>     >>>     There are several "original" versions of that file
>     published by
>     >>>     the IERS, NIST, and USNO.
>     >>>
>     >>>     So for most users it's better to pick up a file from one
>     of the
>     >>>     original sites.
>     >>>
>     >>>>     With [[7]] holding reference to the file hosted at, and a
>     list
>     >>>>     of links to sources.
>     >>>>
>     >>>>     What else is www.ietf.org <http://www.ietf.org>
>     <http://www.ietf.org> hosting of a
>     >>>>     similar nature?
>     >>>>     This file alone is not the only thing hosted under
>     www.ietf.org <http://www.ietf.org>
>     <http://www.ietf.org>
>     >>>>     Internet archive's Wayback Machine [3] shows it appearing
>     back
>     >>>>     in 2015.
>     >>>>
>     >>>>     Who is using the file?
>     >>>     I'm sure the file *is* heavily used, but maybe not
>     directly from
>     >>>     the IETF web site.
>     >>>
>     >>>     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>>     Phone: +49 5281 9309-414
>     >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Warner Losh <[email-masked]>
Date: Wed, 7 Nov 2018 21:14:23 -0700

On Wed, Nov 7, 2018 at 8:58 PM Thomas Peterson <[email-masked]>
wrote:

> this data as no published RFC is dependant on it, and far more authoritive
> sources already provide the data. To answer a question you posted to a
> different part of the thread, I do not believe we have consensus that it be
> removed, let alone have a date of its possible removal. If there is a
> suitable timeline that would help FreeBSD migrate its users please inform
> the list. One of my suggested actions was to discuss with potential
> affected mailing lists as a matter of courtesy so we minimise issues.
>
FreeBSD has shipped a config that fetched this file from IETF's server
starting in Feb 2016. The following releases are affected:

FreeBSD 10.3 2016-04-04
FreeBSD 11.0 2016-10-10
FreeBSD 11.1 2017-07-26
FreeBSD 10.4 2017-10-03
FreeBSD 11.2 2018-06-27
FreeBSD 12.0         2018-12-01 (anticipated).

> condescending manner. It is absolutely not my intention to do so, I am just
> trying to keep my own facts straight.
>
Fair enough. Given the impact of this going away, I was also somewhat
freaking out and may have amplified things more than intended. Please
accept my apologies for freaking out a bit.

There's likely tends to hundreds of thousands of FreeBSD machines are
believed to be installed and pulling from this location from these
releases. Only a subset, of course, care, but how large a subset isn't
known. We'd need some time to move things somewhere else, make sure that's
reliable, etc. We're happy to do this, and aren't demanding the IETF do
anything beyond provide a clear timeline. We'd request the ability to
influence the schedule, but would totally understand if that's not
possible. It's the IETF's decision to make, and I'm trying to provide some
data to help you formulate the proper plans.

Warner

---

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 8 Nov 2018 07:45:32 +0000

Warner,

I’m going to respond more generally to the list, but please rest assured, this file is not going away anytime soon (if indeed it does go away at all). My point in putting the issue on the ntp working group agenda is a housekeeping exercise for the IETF. There is not a desire to stop supporting it. There is a desire to clarify what IETF support entails so we can ensure it is properly supported if needed.

Regards,
Karen

On Nov 8, 2018, at 11:14 AM, Warner Losh <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Nov 7, 2018 at 8:58 PM Thomas Peterson <[email-masked]<mailto:[email-masked]>> wrote:

Myself and others do not believe it is the IETF's responsibility to host this data as no published RFC is dependant on it, and far more authoritive sources already provide the data. To answer a question you posted to a different part of the thread, I do not believe we have consensus that it be removed, let alone have a date of its possible removal. If there is a suitable timeline that would help FreeBSD migrate its users please inform the list. One of my suggested actions was to discuss with potential affected mailing lists as a matter of courtesy so we minimise issues.

FreeBSD has shipped a config that fetched this file from IETF's server starting in Feb 2016. The following releases are affected:

FreeBSD 10.3 2016-04-04
FreeBSD 11.0 2016-10-10
FreeBSD 11.1 2017-07-26
FreeBSD 10.4 2017-10-03
FreeBSD 11.2 2018-06-27

Finally, I apologise if you believe I was speaking in an insulting or condescending manner. It is absolutely not my intention to do so, I am just trying to keep my own facts straight.

Fair enough. Given the impact of this going away, I was also somewhat freaking out and may have amplified things more than intended. Please accept my apologies for freaking out a bit.

There's likely tends to hundreds of thousands of FreeBSD machines are believed to be installed and pulling from this location from these releases. Only a subset, of course, care, but how large a subset isn't known. We'd need some time to move things somewhere else, make sure that's reliable, etc. We're happy to do this, and aren't demanding the IETF do anything beyond provide a clear timeline.. We'd request the ability to influence the schedule, but would totally understand if that's not possible. It's the IETF's decision to make, and I'm trying to provide some data to help you formulate the proper plans.

Warner

On Wed, Nov 7, 2018 at 8:13 PM Thomas Peterson <[email-masked]<mailto:[email-masked]>> wrote:

Right, and have you researched USNO's file? Did you know there's subtle differences between that file and that NIST file? In the past, it has not been updated in a timely manner, and it's expiration date has been unreliable. It's the whole reason FreeBSD doesn't use it: it only kinda sorta looks like the right file. Also, non-military users aren't really supposed to use this source because USNO's charter is to provide support to the military.

This points to a larger problem: There is no authoritative, authenticated file that has this information.  Why should anybody trust the FreeBSD project to say that something is authoritative? At least the NIST file is nominally from an authoritative place (NIST in the US is the source of time, and the file comes from their official services there). USNO's file, when it hasn't skimped on the details, is also an authoritative file provided by USNO to military users. So I don't think your assertion that this is 'non-authoritative' is supported by history or the roles of NIST or USNO to the time community. NIST and USNO have been providing these files for at least two decades that I'm personally aware of. These files are cryptographically checksummed, but not cryptographically signed.

The file that's in FreeBSD isn't the one used for ntpd because it goes stale too quickly. FreeBSD does not necessarily need up to date timezone information to properly function with the current separation of roles. Requiring it to get the files via the timezone database updates to get leapseconds, which are not a time-zone, is inverting the properly designed dependency graph.

Surely it would be more appropriate to learn the history here rather than shooting from the hip and being gratuitously insulting when an issue is raised, but maybe I'm reading too much condescension into your statements. Regardless, it's not helpful to having a civil conversation about it.

Warner

Regards

[2]

On 08/11/2018 02:56, Warner Losh wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     by this change (off the top of my head, [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:pool@lists..ntp.org>>, [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>) as a matter of courtesy
>>>     Denis Reilly  |  Technical Lead  | [email-masked]<mailto:[email-masked]>
>>>     <mailto:[email-masked]<mailto:[email-masked]>> (585)321-5837
>>>
>>>     From: ntp <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
>>>     To: Thomas Peterson <hidinginthebbc@gmail..com<mailto:[email-masked]>>
>>>     <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>>>     <mailto:[email-masked]<mailto:[email-masked]>>
>>>     Cc: Paul Eggert <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
>>>>     https://www.ietf.org/timezones/data/leap-seconds.list<https://www.ietf..org/timezones/data/leap-seconds.list>, but for
>>>>     What else is www.ietf.org<http://www.ietf.org/> <http://www.ietf.org<http://www.ietf.org/>> hosting of a
>>>>     similar nature?
>>>>     This file alone is not the only thing hosted under www.ietf.org<http://www.ietf.org/>
>>>>     <http://www.ietf.org<http://www.ietf.org/>>, in fact https://www.ietf.org/timezones/
>>>>     How long have these files been hosted on www.ietf.org<http://www.ietf.org/>
>>>>     <http://www.ietf.org<http://www.ietf.org/>>?
>>>     Email: [email-masked]<mailto:[email-masked]>
>>>     <mailto:[email-masked]<mailto:[email-masked]>>
>>>     Phone: +49 5281 9309-414
>>>     Websites: https://www.meinberg.de<https://www.meinberg.de/> https://www.meinbergglobal.com<https://www.meinbergglobal.com/>
>>>     Training: https://www.meinberg.academy<https://www.meinberg.academy/>
>>>
>>>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
_______________________________________________
ntp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ntp

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 8 Nov 2018 09:20:42 +0100

Paul Eggert wrote:
> On 11/7/18 11:17 AM, Denis Reilly wrote:
>> As Martin notes, there are better places to get it.
> 
> Those "better places" have often been down or unavailable,
> unfortunately. That's why tzdb distributes a copy.

IMO it's great that a copy of the latest leap second file is included in
tzdb.

However, keeping in mind that the leap second file has an expiration
date, maybe a new version of TZDB should also be released whenever this
file has been updated (that would be twice a year).

If I remember correctly a new release of TZDB is only rolled out when
another timezone change has to be propagated, so the leap second file
via TZDB becomes available more or less delayed.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 8 Nov 2018 09:27:39 +0100

> don't need to run a cron job to fetch it from someplace.

Of course it's OK if distros provide updated leap second files.

However, if folks run a distro which is out of support, and they can't
update for some reason (we have some large customers who do this) they
won't get any updates anymore.

So IMO a good alternative would be to use the new TZDIST protocol to
update their time zone rules, including leap second information.

Once this protocol is widely used even embedded systems (which often
don't get any updates anyway) can update their time zone and leap second
information via the net, justl like they can get the current time via NTP.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 8 Nov 2018 09:51:03 +0100

Warner Losh wrote:
> 'much better places' don't earlier in the thread do not resolve for me
> at all (or resolved to web pages that aren't suitable for automatic
> downloading). The ntp leapsecond file has a format that's been fixed for
> at least two decades. So what's the real 'next step' for people that
> download it outside of the TZ stuff?
> 

Why not use the leap second file directly from the IERS?

The IERS is the authoritative source that decides if a leap second will
be inserted, or not, and it publishes this information twice a year in
its Bulletin C.

Some years ago I contacted the IERS folks and asked them if they
couldn't also provide a leap second file in NTP/NIST format, and they
started to do this. Yet the updated file was always available
immediately when a Bulletin C was published.
https://hpiers.obspm.fr/iers/bul/bulc/ntp/ (directory listing)
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list (file)

Right from the beginning the IERS leap second file was even available
via https, while e.g. from NIST it used to be available via ftp only (I
don't know if currently it's also available via https).

Actually there are discussions on security stuff like NTS to prevent
systems from accepting spoofed time, and IMO it's a no-go to provide
time servers with a leap second file that is retrieved via FTP.

And yes, I agree that the SHA1 signature in the leap second file can
*only* be used to check the integrity of the file. That signature can
not be used to check if the file has provided by an authentic source
like IERS, NIST, or USNO.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 8 Nov 2018 01:24:44 -0800

By default, the "update-leap" script in the Reference Implementation
queries:

   https://www.ietf.org/timezones/data/leap-seconds.list

H

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: "Dieter Sibold" <[email-masked]>
Date: Thu, 08 Nov 2018 16:55:02 +0700

> Why not use the leap second file directly from the IERS?

I very much support this.

> https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list (file)

This link is also provided in draft-ietf-ntp-bcp

---

From: Hal Murray <[email-masked]>
Date: Thu, 08 Nov 2018 03:26:24 -0800

> Why not use the leap second file directly from the IERS?

Depends on the use.  If the target audience is a handful of geeks there is no 
problem.

If it gets added as a cron job to a zillion systems, there is too good a 
chance that something will screwup and DoS their server.

Packaging it with the tzdata seemed like a way to avoid that problem.

If there is a need to run something like a cron job, I think each distro 
should host a copy of the file for their users.

It's possible I'm being overly paranoid.  There are already quite a few ugly 
examples on the wiki NTP abuse page.  I'd be happier if my name as part of 
this discussion didn't get added to another one.
  https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse

Consider the case of a stupid bug in a widely deployed IoT device.

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 8 Nov 2018 12:44:18 +0100

> Consider the case of a stupid bug in a widely deployed IoT device.

Agreed. But it would be the benefit of using the TZDIST protocol that
this could work similar to a combination of DNS and the NTP pool:

A "root" TZDIST server could be provided with an update, so secondaries
or pool servers could grab the information and pass it on down the line
to the final clients.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Sanjeev Gupta <[email-masked]>
Date: Thu, 8 Nov 2018 23:41:35 +0800

> via TZDB becomes available more or less delayed.

The tzdb updates frequently (we have had 7 so far this year, and a couple
more may still happen as countries adjust their Mar DST settings).

IERS issues Bulletin C early in Jan and July each year, even when no change
is planned.  A list of previous bulletins is here:
 https://datacenter.iers.org/availableVersions.php?id=16

I estimate that there are about 60 changes to tzdb, and 4 releases, every
six months.  A leap second gets added every couple of years.or so.  It is
unlikely that tzdb would not have a current and correct copy of the IERS
Bulletin.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Nov 2018 17:01:16 +0000

> immediately when a Bulletin C was published.

It isn't quite as reliable as that, I'm afraid.

In June 2017 (shortly before Bulletin C 54) the IERS Leap_Second.dat file
nearly expired becuse it wasn't updated to reflect Bulletin C 53. That
didn't add any leap seconds, but the IERS data file lists both the date
and number of the most recent Bulletin C and its expiry time, and those
details should be correct.

(I notice these things because I have some code which maintains leap
second listings in the DNS in various formats at leapsecond.dotat.at. My
script fetches data from the IERS, NIST, and USNO, and compares them for
consistency before updating the DNS, and in recent years there has usually
been a significant delay updating at least one of the source files after
Bulletin C is promulgated.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
the quest for freedom and justice can never end

---

From: Hal Murray <[email-masked]>
Date: Thu, 08 Nov 2018 12:36:30 -0800

[email-masked] said:
> Agreed. But it would be the benefit of using the TZDIST protocol that this
> could work similar to a combination of DNS and the NTP pool:

> A "root" TZDIST server could be provided with an update, so secondaries or
> pool servers could grab the information and pass it on down the line to the
> final clients. 

Is there code available?  Server?  Client?

Should we ask IANA to run a server?

---

From: Paul Eggert <[email-masked]>
Date: Thu, 8 Nov 2018 13:39:39 -0800

> * The IETF ceases to host unpacked versions of tzdb

I'm not sure exactly what is being proposed here. That being said, the 
tzdb distribution <https://www.iana.org/time-zones> is not going to 
remove the leap-seconds.list file. That file is used by tzdb itself and 
(like it or not) many downstream packages depend on it. Whatever problem 
you're trying to solve, removing leap-seconds.list can't be part of the 
solution.

A couple of the suggestions in this thread have also been made in the tz 
mailing list, and have been rejected because they have problems.

* Other "far more authoritative sources" for the leap-seconds.list file 
have been unreliable in practice: for example, they use FTP servers that 
are often unavailable. I've had to wait weeks to get the file in some cases.

* tzdb cannot use the leap second file directly from the IERS because 
that file is copyrighted, whereas leap-seconds.list is public domain.

---

From: Thomas Peterson <[email-masked]>
Date: Fri, 9 Nov 2018 01:01:58 +0000

Apologies, please allow me to clarify.

This discussion is around putting forward a suggestion of action for the 
IETF's hosting of tzdb on IETF infrastructure as no published 
specification mandates so. There is no discussion here to remove 
"leap-seconds.list" from the tzdb distribution. If that was a subject I 
wished to propose it would have been raised in a more appropriate forum 
such as the tz mailing list.

Regards

On 08/11/2018 21:39, Paul Eggert wrote:
> remove the leap-seconds.list file. That file is used by tzdb itself 
> and (like it or not) many downstream packages depend on it. Whatever 
> problem you're trying to solve, removing leap-seconds.list can't be 
> part of the solution.
>
> A couple of the suggestions in this thread have also been made in the 
> tz mailing list, and have been rejected because they have problems.
>
> * Other "far more authoritative sources" for the leap-seconds.list 
> file have been unreliable in practice: for example, they use FTP 
> servers that are often unavailable. I've had to wait weeks to get the 
> file in some cases.
>

---

From: Thomas Peterson <[email-masked]>
Date: Fri, 9 Nov 2018 01:32:25 +0000

I don't think you are being paranoid and that your suggestion to let the 
distros handle the distribution is absolutely appropriate. A potential 
point of contention comes when some open source based distributions with 
limited resources have to find means of hosting data such as this in 
efficient means due to their much more finite resources.

Judging by a lot of the discussions that have been made through the past 
day on this subject it appears we have seen some concerns raised about 
pulling rug out from underneath at least one distribution, suggestions 
to look at extending protocols and many useful clarifications with 
regards to ownership, stewardship, and responsibility of the LSL.

I think it will require several pieces of work in parallel to avoid 
negative outcomes. It make sense for those interested in seeing an 
enhancement to TZDIST to explore the work to include this data (and I 
would be happy to help where I can, despite being unfamiliar with the 
standard) and at the same time the distributions dependant on the IETF's 
hosting of LSL work with the IETF to consider moving away from depending 
on it in a way that minimises any loss of service, and improves things 
for their users.

Regards

---

From: Paul Eggert <[email-masked]>
Date: Thu, 8 Nov 2018 17:35:11 -0800

On 11/8/18 5:01 PM, Thomas Peterson wrote:
> This discussion is around putting forward a suggestion of action for 
> the IETF's hosting of tzdb on IETF infrastructure as no published 
> "leap-seconds.list" from the tzdb distribution.

Right, and that's where I don't know exactly what is being proposed 
here. Let me try to clarify. Currently tzdb is published at 
https://www.iana.org/time-zones which has many subsidiary URLs such as:

* https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz is the 
latest tzdb release as a compressed tarball.

* https://www.ietf.org/timezones/data/zone1970.tab is the latest tzdb 
release of a list of timezones as a text file

* https://www.ietf.org/timezones/data/leap-seconds.list is the latest 
tzdb release of the leap-seconds.list file under discussion in this thread.

Are these URLs considered to be "the IETF's hosting of tzdb"? That is, 
is there a suggestion that the IETF stop hosting these files at this 
location? If so, we'll need to prepare a transition strategy for a 
different hosting location for tzdb, because we can't reasonably remove 
the leap-seconds.list file from tzdb for the reasons previously discussed.

Or, if these URLs do not count as "the IETF's hosting of tzdb", then why 
has this topic come up recently?

---

From: Thomas Peterson <[email-masked]>
Date: Fri, 9 Nov 2018 04:40:05 +0000

I was intending to keep the scope of this discussion solely on what is 
hosted under the ietf.org domain. There also does not appear to be links 
from the IANA time zone page you link nor from any of the downloads that 
contain specific reference to the second and third links in your email, 
so could you please clarify how those are announced?

As has already been discussed in other parts of this thread around the 
FreeBSD usage, if the decision is for the IETF to cease serving tzdb 
data under ietf.org domains, I would expect there to be a transition 
strategy including appropriate comms sent out, which I would be happy to 
assist with.

Regards

On 09/11/2018 01:35, Paul Eggert wrote:
> different hosting location for tzdb, because we can't reasonably 
> remove the leap-seconds.list file from tzdb for the reasons previously 
> discussed.
>
> Or, if these URLs do not count as "the IETF's hosting of tzdb", then 
> why has this topic come up recently?
>

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 9 Nov 2018 09:28:09 +0100

Sanjeev Gupta wrote:
> On Thu, Nov 8, 2018 at 4:20 PM Martin Burnicki
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> The tzdb updates frequently (we have had 7 so far this year, and a
> couple more may still happen as countries adjust their Mar DST settings).
> 
> IERS issues Bulletin C early in Jan and July each year, even when no
> change is planned.  A list of previous bulletins is here:
> I estimate that there are about 60 changes to tzdb, and 4 releases,
> every six months.  A leap second gets added every couple of years.or
> so.  It is unlikely that tzdb would not have a current and correct copy
> of the IERS Bulletin.

I'm aware of all these facts. However, even if *no* leap second is to be
added the leap seconds file needs to be updated, at least if the target
system also derives the current TAI offset from the file.

This is because the file has an expiration date, and after the the
expiration date a system is unable to distinguish if no leap second
after the latest one in the existing file has been added, or if there
might have been an additional leap second, but the information (i.e. the
file) hasn't been updated.

So IMO if a new version of TZDB only relies on changes in the TZ rule of
some country then the leap second file update via TZDB may be very late
if countries stop changing their TZ rules.

I know this is probably not really going to happen. ;-)

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 9 Nov 2018 09:38:45 +0100

> Bulletin C is promulgated.)

I know. I'm also monitoring this.

When the folks at IERS started providing a leap second file they also
didn't really know how they should set the file's expiration date.
However, the latest updates of the file were published quickly and
correctly.

Of course every metrology institute is an authoritative source for such
information, but IMO the IERS is the most authoritative one since the
IERS decides whether to ad another leap second, or not.

Beside this there's also a cultural aspect. The IERS is an
*international* organization, while NIST and USNO are American organization.

For me personally this difference doesn't matter much but there are
other countries which are not very America-friendly, which may want to
avoid relying on a service provided by the USA.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 9 Nov 2018 10:15:17 +0100

> Is there code available?  Server?  Client?

During the discussion of the protocol there was a tzdist mailing list
hosted at IETF.
https://www.ietf.org/mailman/listinfo/tzdist

However, this original mailing list doesn't seem to exist anymore, but
the archive is still there:
https://www.ietf.org/mail-archive/web/tzdist/current/maillist.html

In the meantime, 2 new mailing lists have been created:

tzdist-bis      https://www.ietf.org/mailman/listinfo/tzdist-bis
tzdist-service  https://www.ietf.org/mailman/listinfo/tzdist-service

(I already knew about the first one, but just discovered the 2nd a
minute ago)

What I recall from memory is that there are test implementations for
client and server, and a test server was online. I don't know if it
currently still is.

Anyway, AFAICS there are still some problems to resolve: how to
integrate the data a client receives from a server.

Once I have a TZDIST server running, and a client that receives the
data, how to use the received data?

Can the TZDIST client update a local TZDB file on the fly?

If it can do this, can an application detect that the TZ rules may have
been updated, and seamlessly start using the new rules, or has the
application to be restarted to let the new TZ rules take effect?

In a recent discussion (I think it was on the TZ mailing list) someone
said that certain versions of IOS and Android may have some other ways
to update their timezone information, but the device has to be
*rebooted* to let the changes take effect.

Similar e.g. for ntpd and the leap second file: A current versions of
ntpd detects at runtime when the specified leap second file has been
updated, and re-reads the file, so the leap second and TAI information
can be updated on the fly.

However, a TZDIST client would need to be able to (re-)write a leap
second file if required, or some other mechanism needed to be invented
to pass the updated data to ntpd.

So IMO here's still much room for improvements.

Some time ago I proposed on some mailing list to try to get a "Google
Summer Of Code" project for some implementation, but that didn't happen.

I have to admit that lately I haven't followed the TZDIST discussions
very closely, so there might have been some progress in the mean time.

Sorry for the long post which is partly off topic here, but IMO there
are a number of things that need to be considered for an overall time
synchronization system.

> Should we ask IANA to run a server?

IMO This would only make sense if there are clients that interact and
integrate seamlessly with other time synchronization components.

Anyway, I think this is a very good approach, and the preferred
direction to go.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 9 Nov 2018 10:18:13 +0100

> that file is copyrighted, whereas leap-seconds.list is public domain.

I fully agree.

This is *one* possible way to distribute leap second/TAI information.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Danny Mayer <[email-masked]>
Date: Fri, 9 Nov 2018 10:47:47 -0500

I have been following this discussion and I'd like to push the reset
button. Discussion about the tz database is not just off-topic but is
irrelevant to this working group. Many people on this list may be
interested but there are other forums for that.

My understanding is that IERS is the body responsible for deciding when
to declare a leap-second. From the point that they announce a
leap-second there are various methods used to distribute that
announcement. From my understanding of this from then on there is an
informal process to add the information into leap-second files and those
distributed to various different places around the internet. The first
part is a manual process and requires a human being to do that. The
distribution of the information seems to be a vague process. The various
standards agencies such as NIST in the US are government agencies and as
such are only responsible for standards and information in their own
countries though you would expect that they are responsible more making
available a leap-second file.

So the real question is whether or not we need to formalize the
distribution of the leap-second file and how would we accomplish that?
Also how would it be kept uptodate? For that matter is there an
agreed-upon standard format for the contents of the leap-second file?

Danny

---

From: Steve Allen <[email-masked]>
Date: Fri, 9 Nov 2018 10:11:06 -0800

On Fri 2018-11-09T10:47:47-0500 Danny Mayer hath writ:
> to declare a leap-second.

> The distribution of the information seems to be a vague process.

The IETF inherited this responsibility in 1988 from the original
responsible agency, International Time Bureau (BIH).  The process has
never been specified other than a leap second must be announced at
least 8 weeks in advance.  This made sense at the date of the original
recommendation 460 in 1970 because at that time BIH was publishing
Bulletin Horaire every two months.  No regulation required BIH nor
requires IERS to publish this information in a machine-accessible
format, and no there is no source of funds for publishing with a
robust technology.

This timekeeping tragedy-of-the-commons can be seen at least as far
back as 1925 when broadcast time signals were being used by navigators
of vessels, commercial clock setting operations, surveyors, and
geodecists around the world.  The IAU was paying all of the expenses
of running the BIH and wondering if maybe they could get the IUGG to
contribute some funds toward the understanding of why different time
broadcasts disagreed and studying ways of improving their
synchronization

http://adsbit.harvard.edu/cgi-bin/nph-iarticle_query?bibcode=1926BuBIH...2..123S&db_key=AST&page_ind=20&data_type=GIF&type=SCREEN_VIEW&classic=YES

--
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: Warner Losh <[email-masked]>
Date: Fri, 9 Nov 2018 11:35:08 -0700

> agreed-upon standard format for the contents of the leap-second file?

The format is "standardized" in a fashion. It's documented in the
leap-second file itself, and all NTP implementations use the same format.
I'd be surprised if the current ntp standard doesn't define it (I've not
checked).

There's at least 5 other formats this data exists in on the internet, but
ntp doesn't use them, nor do people grab that data and convert to the ntp
leap-second.txt format unless they happen to need it for other purposes and
get a 'twofer' by doing so.

It would be possible to generate the file from the archive of Bulletin-C's
that IERS publishes, coupled with the programs that are available at the
same web locations to add the SHA1 checksum data. Scraping them from the
IERS web site would be straight forward. To do it adequately, you run the
cron job Feb 1 and Aug 1 and you'll be able to generate the new file then.
To do it robustly, you may need to things monthly or weekly (as 460's
schedule for leap seconds allows the end of any month to have one), but
then you get into the crazy world of edge-case-hell that people that try to
guess from the current standards what future IERS edicts say get into. Do
you make it future proof, or do you assume that past practice is sacrosanct
and that any deviation from it will generate a new standard, or do you
assume they will follow 460's recommendations that people have, at best,
imperfectly implemented outside of June/December leap seocnds? When I was
younger, I'd say follow the published spec (and I did that at least twice
in my carer). Now I'd say follow existing practice and cope if they change
it. Testing of even the secondary dates showed that far too many things get
things wrong there (and some well known bugs where leap indications were
turned on too early lead some devices to bogusly assume it was the
march/september dates, even though the data in the data stream clearly
indicated the right dates).

As for what's best to do to keep it up to date? Beats me. It's more of the
tragedy of the time commons that Dr Allen referred to that something this
simple and basic has been so manual for so long.

Warner

---

From: Paul Eggert <[email-masked]>
Date: Fri, 9 Nov 2018 13:12:38 -0800

On 11/8/18 8:40 PM, Thomas Peterson wrote:
> hosted under the ietf.org domain.

Although the intent was that leap-seconds.list (as part of tzdb) be 
distributed via iana.org URLs, it is also distributed under ietf.org 
because  <https://data.iana.org/time-zones/> and 
<https://www.ietf.org/timezones/> are clones.

I don't know why the ietf.org URLs exist. I don't even recall knowing 
about them until this discussion. However, it appers that access via 
ietf.org is common. If I search Google for "leap-seconds.list" the first 
hit is the ietf.org copy (the iana.org copy isn't even in the top ten), 
and I sent ietf.org URLs to you in my previous email because I Googled 
for files without noticing that the resulting URLs were ietf.org and not 
iana.org.

In looking for why people seem to prefer ietf.org URLs, I see that NTP 
started using them for leap-seconds.list in NTP version 4.2.8p9 
(2016-11-21) presumably because the nist.gov URLs were so flaky. My 
guess is that the NTP developer in question didn't know that iana.org 
was intended and ietf.org was (at least from the tzdb point of view) 
accidental. I assume we can file a bug report with the NTP developers to 
replace ietf.org URLs with iana.org URLs, though it will take some time 
for any such change to trickle out to real-world use.

If the intent is to decommission the ietf.org URLs, I think we're all 
agreed that we should give NTP and other downstream users sufficient 
advance notice of the switch. I also suggest redirecting 
leap-seconds.list (and other tzdb-related) HTTPS requests from ietf.org 
to iana.org after the decommission occurs.

I will ask the iana.org webmasters why there are ietf.org clones of the 
URLs in question. Quite possibly there's a good reason that I don't know.

> There also does not appear to be links from the IANA time zone page 
> you link nor from any of the downloads that contain specific reference 
> to the second and third links in your email, so could you please 
> clarify how those are announced? 

Tzdb releases are announced on [email-masked] which is described 
at <https://mm.icann.org/mailman/listinfo/tz-announce>. (I don't know 
why the mailing list is archived is at icann.org and not iana.org; I 
suppose that's another question I can ask the iana.org webmasters, if 
there's interest.)

The most recent tzdb release announcement is archived at 
<https://mm.icann.org/pipermail/tz-announce/2018-October/000052.html>. 
Releases are distributed via HTTPS (also plain HTTP or FTP, but these 
are deprecated). Each release announcement contains GPG checksums for 
the release files, so the leap-seconds.list file in each distribution 
can be checked by verifying these checksums.

---

From: Paul Eggert <[email-masked]>
Date: Fri, 9 Nov 2018 13:41:09 -0800

> data, how to use the received data?

The data will give you a series of transitions for a particular 
timezone, and these transitions can include the sort of leap-second info 
in leap-seconds.list. The transitions can be represented in multiple 
formats. The only format currently specified is iCalendar format (RFC 
5545), though it should be easy to add specs for other formats, such as 
the TZif binary format that tzcode uses to distribute leap-second data 
(see <https://tools.ietf.org/html/draft-murchison-tzdist-tzif-15>). I 
suppose it would be possible to shoehorn the leap-seconds.list text file 
format into TZDIST, e.g., by asking a TZDIST server for info about the 
UTC time zone in "leap-seconds.list" format.

> Can the TZDIST client update a local TZDB file on the fly?

It could, yes. In practice I don't know of anybody doing that in 
production. This stuff is reasonably bleeding-edge.

> application to be restarted to let the new TZ rules take effect?

Application seamlessness is outside the scope of TZDIST.

TZDIST does let a client ask a server "have the rules changed in any 
timezone?" efficiently, and this includes any changes to leap seconds. 
TZDIST doesn't provide any way for a server to push notifications of 
leap-second changes to clients, though.

---

From: Jared Mauch <[email-masked]>
Date: Fri, 9 Nov 2018 17:30:25 -0500

> On Nov 8, 2018, at 4:24 AM, Harlan Stenn <[email-masked]> wrote:
> 

This may be poor behavior updating it from a source that perhaps isn’t well maintained.

I was the one at the mic advocating that without a document saying it is hosted at IETF it should go away.

What this also means is that if someone writes up a doc saying it should live at the IETF that would remove my primary concern.

There are the secondary issues of what NTP implementations use it.  I would like to know if it’s just FreeBSD users that fetch it and the frequency, etc.

I suspect it’s not often, and if the file is not well maintained, publishing it at the IETF without documenting how and when it’s updated may actually make things worse if we don’t prescribe some procedure to maintain it.

If it’s a relic of a single implementation (whatever form/type it is), perhaps it’s best for them to maintain the document and update it at their site.  It’s also perhaps too late, but if this file is so important, is it described in the BCP for operating NTP, or is this yet another esoteric NTP thing that’s not well documented so ends up being inconsistently used?

I would be interested in seeing an implementation report for who uses it.  (I would also perhaps argue that freebsd-update is not really a consumer of it).

- Jared

---

From: Warner Losh <[email-masked]>
Date: Fri, 9 Nov 2018 16:16:44 -0700

On Fri, Nov 9, 2018 at 3:30 PM Jared Mauch <[email-masked]> wrote:

> There are the secondary issues of what NTP implementations use it.  I
> would like to know if it’s just FreeBSD users that fetch it and the
> frequency, etc.
>

FreeBSD users fetch it, by default, twice a year with a random smear around
a month before it expires. There's around ~100,000 FreeBSD systems
installed that fetch this, give or take. The project has no hard numbers,
and I've seen estimates as high as 1 million for the number of machines
running some flavor of FreeBSD.

I have no idea if other users fetch it as well...

> If it’s a relic of a single implementation (whatever form/type it is),
> perhaps it’s best for them to maintain the document and update it at their
> site.  It’s also perhaps too late, but if this file is so important, is it
> described in the BCP for operating NTP, or is this yet another esoteric NTP
> thing that’s not well documented so ends up being inconsistently used?
>

It's the best source of this file in the internet. That's why FreeBSD is
using it. I won't argue that it may not be the best documented thing in
NTP...

> I would be interested in seeing an implementation report for who uses it.
> (I would also perhaps argue that freebsd-update is not really a consumer of
> it).
>

freebsd-update isn't a consumer of it, nor has that been claimed. There's a
periodic script that runs a couple of times a year that fetches the file
independently of freebsd-update. It's hard to argue that FreeBSD users
doesn't use and/or fetch this file since it is enabled by default in a part
of the system that's not often changed from the defaults.

The FreeBSD project is looking for ways to transition away from doing this,
but at the moment it would create a big problem were the file to suddenly
disappear.

Warner

---

From: Thomas Peterson <[email-masked]>
Date: Sun, 11 Nov 2018 07:38:49 +0000

Thank you Paul for the further clarity around the hosting - I was 
unaware that data.iana.org also hosted it simply because search engines 
don't appear to know about it, which is strange to me as the robots.txt 
on www.iana.org and data.iana.org do not prohibit spiders on the URLs in 
question.

Harlan: If yourselves and the IANA webmasters do not object, would it be 
possible to raise a bug with ntp to change the URL used by 
'update-leap'? I would have done so myself however new accounts appear 
to require approval.

Regards

On 09/11/2018 21:12, Paul Eggert wrote:
>> I was intending to keep the scope of this discussion solely on what 
>> is hosted under the ietf.org domain.
>
> ietf.org is common. If I search Google for "leap-seconds.list" the 
> first hit is the ietf.org copy (the iana.org copy isn't even in the 
> top ten), and I sent ietf.org URLs to you in my previous email because 
> I Googled for files without noticing that the resulting URLs were 
> ietf.org and not iana.org.
>
> accidental. I assume we can file a bug report with the NTP developers 
> to replace ietf.org URLs with iana.org URLs, though it will take some 
> time for any such change to trickle out to real-world use.
>
> leap-seconds.list (and other tzdb-related) HTTPS requests from 
> ietf.org to iana.org after the decommission occurs.
>
> I will ask the iana.org webmasters why there are ietf.org clones of 
> the URLs in question. Quite possibly there's a good reason that I 
> don't know.
>
>
>> you link nor from any of the downloads that contain specific 
>> reference to the second and third links in your email, so could you 
>> please clarify how those are announced? 
>

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 11 Nov 2018 02:54:12 -0800

> 'update-leap'? I would have done so myself however new accounts appear

Sure, and only gmail accounts require approval - we get too much spam
otherwise and gmail has never shown a care that spammers do this.

I'll point out that the default URL for the leap seconds file is a
*default* and people can easily specify an override.

But yes, if there's a better source for this file we're happy to make
that change.

H
--

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 12 Nov 2018 09:25:59 +0100

Danny,

> interested but there are other forums for that.

The folks in the NTP WG are discussing how NTP is supposed to work.

The leap second file which is (among other ways) distributed via TZDB is
an important requisite for a full featured NTP server operation.

Of course there are other platforms to discuss more details, but you
don't always know who is on which platform.

It's very important that the WG folks at least know that this stuff and
variants of it exist, so IMO it's perfectly fine to discuss at least
some basics here.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 12 Nov 2018 12:34:01 +0100

>>> Paul Eggert <[email-masked]> schrieb am 08.11.2018 um 22:39 in
Nachricht
<[email-masked]>:
> tzdb distribution <https://www.iana.org/time‑zones> is not going to 
> remove the leap‑seconds.list file. That file is used by tzdb itself and 
> you're trying to solve, removing leap‑seconds.list can't be part of the 
> solution.

So if TZ data depend on the leapsecond list, the previous discussion on
whether the TZ data wil be updated frequently enough should be solved: In my
view of things new TZ data should be made availale whenever a new leapsecond
file is available (or at least significantly before the last one expires).

[...]

Regards,
Ulrich

---

From: Warner Losh <[email-masked]>
Date: Mon, 12 Nov 2018 10:32:55 -0700

> file is available (or at least significantly before the last one expires).

I think the probability of that is approaching 1.0

Let's look at the timeline...

First week or so in January Bulletin C comes out
By Feb 1 new leap file that expires December-ish (it's technically valid
until Dec 31 23:59:58, but the practice has been to expire a bit before
then, IIRC, December 1st).
Then July comes around and we do it again: by august 1st a new leap file is
available, expiring June 1.

So worst case we have a 4 month window. If a TZDB release were done the day
before a new leap file, you'd have 4 months to do another release to be
"just in time".

Going back to 2010, I see the following releases: 2018g, 2012j, 2011n,
2010o (based on a quick grep of the FreeBSD vendor imports, which is
imperfect data). Each of these years shows at least monthly releases based
on the letter suffix... So there's approximately monthly releases. Worst
case, there's a 4 month window. I think we're good, and if there were a 3
month period where there were no tz changes, a special one for the new leap
file could be made either in early May or November.

Warner

---

From: Paul Eggert <[email-masked]>
Date: Mon, 12 Nov 2018 09:42:54 -0800

Ulrich Windl wrote:
> new TZ data should be made availale whenever a new leapsecond

Of course, but how long is "significantly"?

Time zone announcements are sometimes made by governments with very little 
notice; for example, we had only 39 hours' notice for last month's change to 
Morocco's rules. (These governments are being unrealistic of course, but we're 
trying to train them by arranging for their cell phones' clocks to be wrong if 
they don't give us more notice. :-) Although the tzdb process turns around such 
notices reasonably quickly we prefer being given longer notice; in that case we 
wait for a while because there is a cost to releasing a new tzdb version (a cost 
to us and more importantly to downstream users) and we'd like to lessen that 
cost by batching multiple changes into a single release. Plus, sometimes 
governments revert their changes before they take effect, or we're given false 
alarms for other reasons, and in such cases we can avoid releasing the wrong data.

In contrast, we reliably get about six months' notice for a leap second. We 
batch that into the next tzdb release, whenever it happens to occur for other 
reasons. We've never had the problem of no timezone changes for six months so 
this has been good enough for us. (We would make a release for leap seconds 
reasons only, if need be.)

Some users who need just the leap-seconds.list file have written to the tz 
mailing list saying that they don't want to wait for the next tzdb release; they 
want the latest leap-seconds.list file now, even if its set of leap seconds is 
identical to the previous set (because they also want the file's expiration 
date). These users are not well-served by the current tzdb release policy which 
is oriented for tzdb's needs, not for leap-seconds.list needs. Are these users 
primarily motivated by NTP? If so, what's the use case here and why is the 
expiration date so important? (That date is ignored by tzcode.) I can't imagine 
maintaining an NTP server without having a mechanism to update its leap second 
data that could work with (say) a month's notice which would mean that the 
current tzdata policy should be good enough, but I'm not that plugged into how 
NTP servers are actually deployed.

If the need is great enough, it'd be helpful to set up a distribution mechanism 
for just leap-seconds.list that fulfills NTP's needs better and I could talk to 
the IANA folks about doing that. Of course iana.org wouldn't want to be 
overloaded by billions of devices constantly polling it....

---

From: Jared Mauch <[email-masked]>
Date: Mon, 12 Nov 2018 12:48:23 -0500

> On Nov 12, 2018, at 12:42 PM, Paul Eggert <[email-masked]> wrote:
> 
> If the need is great enough, it'd be helpful to set up a distribution mechanism for just leap-seconds.list that fulfills NTP's needs better and I could talk to the IANA folks about doing that. Of course iana.org wouldn't want to be overloaded by billions of devices constantly polling it....

There was the case where when the root zone was signed and a specific Apple software update went out they saw a huge number of devices fetching the keys.

I’m sure if there was some significant number of devices that needed it, it might be enough to be noticeable.

I would worry more about that if we had a way to authenticate the source(s) of time though and a client needed to fetch keys for all their sources.

- Jared

---

From: Hal Murray <[email-masked]>
Date: Mon, 12 Nov 2018 11:29:49 -0800

[email-masked] said:
>> new TZ data should be made availale whenever a
>> new leapsecond file is available (or at least significantly
>> before the last one expires).

>  reasons. We've never had the problem of no timezone changes for six months
> so  this has been good enough for us. (We would make a release for leap
> seconds  reasons only, if need be.) 

I think things will be fine as long as you are willing to push out a leap-only 
release if nothing else happens for a month.  The point is that you don't get 
the whole 6 months.

Here is my list of the steps that have to happen for sites that get it via 
their distro:
  1: IERS announces leap or non-leap via bulletin C
  2: NIST updates leap-seconds.txt
  3 TZDB releases updated copy from NIST
  4  distro releases update to TZDB
  5  end system picks up new TZDB from distro
  6  ntpd announces to downstream clients
  
If we assume the first two steps take a month and allow a month each for steps 
3, 4, and 5, that still leaves a month of slop if the announcements are to get 
out a month early.

---

From: Warner Losh <[email-masked]>
Date: Mon, 12 Nov 2018 12:43:40 -0700

> 3, 4, and 5, that still leaves a month of slop if the announcements are to

The deadline for #6 is leap-second day, correct? ntpd only announces an
impending leap second in the last 24 hours before the leap second. Or is
that just a reference implementation detail. When there's no leap second
the deadline is a few days before since that's the expiration of the
previous file.

Also, to be clear, as far as ntpd is concerned, steps 3, 4, 5 are all
*optional* if there's another mechanism to pull in a new leap-second.txt
file from elsewhere. #5 implies an upgrade of at least some of the packages
on the system. While that's *A* way to do it, there are other equally valid
ways. We should allow for the extra time, of course, for this to happen.

I don't think we need to, however, allow for a worst case scenario where
IERS announces 8 weeks prior to the leap second. While that's technically
the current documented SLA (or was when i last checked), I believe they've
adopted first week in January deadline for when there's is a leap second
because it's now clear 3 months before that whether or not there will need
to be one. TOD forecasting has come a long way since 1972.

tl;dr: I think the current release cycle of the tzdb folks address the
needs here adequately.

Warner

P.S. Sorry if I'm being too nit-picky here, but traditionally there's been
a wide diversity of methods for obtaining leap-seconds.txt, and it would be
premature to standardize on the above list.

---

From: "Dieter Sibold" <[email-masked]>
Date: Mon, 12 Nov 2018 21:42:00 +0100

> The IETF inherited this responsibility in 1988 from the original

I suppose you meant to say ‚The IERS inherited this responsibility 
…‘. Correct?

---

From: Steve Allen <[email-masked]>
Date: Mon, 12 Nov 2018 14:12:16 -0800

On Mon 2018-11-12T21:42:00+0100 Dieter Sibold hath writ:
> I suppose you meant to say ‚The IERS inherited this responsibility …‘.
> Correct?

Yes. Too many initials.

Note that IERS is not a monolithic entity.  IERS is an umbrella over
numerous bureaus, each of which tends to some aspects of the overall
mission.  The bureau that inherited from BIH the responsibility for
earth orientation as a measure of the passage of calendar days, and
thus for the leap seconds which keep calendar days being a count of
earth rotations, is the Paris bureau.

---

From: Dieter Sibold <[email-masked]>
Date: Tue, 13 Nov 2018 12:39:25 +0000

Hello Martin,

not speaking as WG chair. 

I want to support Danny's intention. Albeit I appreciate this comprehensive discussion it is obvious that the TZDB is of low relevance for NTP. The discussion about the leap second file is another story. It is most helpful to disseminate leap seconds in a predictable and robust way. However usage and interpretation of the leap second file is not standardized and hence depends on the NTP implementation considered. Taken that probably most of the current NTP clients are not based on ntpd anymore, the failure not to specify how the leap second file is maintained, disseminated, and how it interacts with the leap second information disseminated by upstream servers via the NTP leap second bit is a somewhat unsatisfactory situation.

I also want to mention that the leap second file is in my opinion not a requisite for a fully featured NTP server. You can disseminate a forthcoming leap second event without a leap second file. RFC 5905 does not mandate a leap second file to achieve this.

- Dieter

Am 12.11.18, 09:26 schrieb "Martin Burnicki" <[email-masked]>:

    Danny,

    

    
    Martin
    -- 
    Martin Burnicki
    
    Senior Software Engineer

---

From: Paul Eggert <[email-masked]>
Date: Wed, 7 Nov 2018 11:53:30 -0800

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 22 Nov 2018 07:55:49 +0000

In one of my earlier emails I noted that no document that I could find 
makes reference leap second file, with the exception of Section 4.6 of 
draft-ietf-ntp-bcp. To focus this discussion away from the question of 
hosting the data and onto something probably more relevant to this 
working group mailing list, I would like to propose amending said draft:

Current:

     "The IETF maintains a leap second list [7] for NTP users who are 
not receiving leap second information through an automatic source."

Proposed:

     "IANA maintains a leap second list [7] for users who are not 
receiving leap second information through an automatic source."

In addition to the link in [7] being replaced with 
https://data.iana.org/time-zones/tzdb/leap-seconds.list.

Regards

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 22 Nov 2018 08:03:41 +0000

My apologies to all, I noticed I was looking at the older version of the 
draft.

With that I instead propse the IANA link referenced be mentioned first 
in the section covering leap seconds, as the other files are derived 
from it.

Regards

On 22/11/2018 07:55, Thomas Peterson wrote:
>> I want to support Danny's intention. Albeit I appreciate this 
>> comprehensive discussion it is obvious that the TZDB is of low 
>> relevance for NTP. The discussion about the leap second file is 
>> another story. It is most helpful to disseminate leap seconds in a 
>> predictable and robust way. However usage and interpretation of the 
>> leap second file is not standardized and hence depends on the NTP 
>> implementation considered. Taken that probably most of the current 
>> NTP clients are not based on ntpd anymore, the failure not to specify 
>> how the leap second file is maintained, disseminated, and how it 
>> interacts with the leap second information disseminated by upstream 
>> servers via the NTP leap second bit is a somewhat unsatisfactory 
>> situation.
>>
>> I also want to mention that the leap second file is in my opinion not 
>> a requisite for a fully featured NTP server. You can disseminate a 
>> forthcoming leap second event without a leap second file. RFC 5905 
>> does not mandate a leap second file to achieve this.
>>
>> - Dieter
>>
>>
>>
>>      > I have been following this discussion and I'd like to push the 
>> reset
>>      > button. Discussion about the tz database is not just off-topic 
>> but is
>>      > irrelevant to this working group. Many people on this list may be
>>      > interested but there are other forums for that.

---

From: Denis Reilly <[email-masked]>
Date: Tue, 27 Nov 2018 18:55:25 +0000

Hello Thomas,

I am not sure whether the other files are derived from the IANA link. From what I can tell, it's probably the opposite: the files at NIST or IERS may get updated first, then they get pushed to the IANA. And the main goal of IANA's effort is keeping tzdb up to date; the leap seconds file is simply part of it.

If we mention the IANA link at all, I'd prefer language like "IANA also hosts a copy of the Leap Seconds file[1], as part of the Time Zone Database[2].", with [1] linking to https://data.iana.org/time-zones/tzdb/leap-seconds.list , and [2] linking to https://www.iana.org/time-zones . This I think makes it clear that the main role of IANA here is to maintain tzdb.

I'd prefer to leave it out entirely, though, as I did for draft -08. I think the three sources listed are good enough for the BCP. 

-----Original Message-----
From: ntp <[email-masked]> On Behalf Of Thomas Peterson
Sent: Thursday, November 22, 2018 3:04 AM
To: Dieter Sibold <[email-masked]>; Martin Burnicki <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Ntp] Finding leap-seconds.list

My apologies to all, I noticed I was looking at the older version of the draft.

With that I instead propse the IANA link referenced be mentioned first in the section covering leap seconds, as the other files are derived from it.

Regards