Re: [Ntp] Finding leap-seconds.list

Karen O'Donoghue <odonoghue@isoc.org> Thu, 08 November 2018 07:45 UTC

Return-Path: <odonoghue@isoc.org>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA381294D0 for <ntp@ietfa.amsl.com>; Wed, 7 Nov 2018 23:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59Pm4pk8XIZe for <ntp@ietfa.amsl.com>; Wed, 7 Nov 2018 23:45:36 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9C3124408 for <ntp@ietf.org>; Wed, 7 Nov 2018 23:45:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=McvCtBPJDO/LAjnX9DIBC8YpnNKTnWUJtxKo6gXaFdQ=; b=sAyJCo4KlixKLLIf3Nw596KlOdV1RmhCMILeYZYIQEgum1UvQs0r8PoSDZluVHavRtCwrZLeKkWEGakxaKk0BxGYnYLIwHOVR7+iyLCfSocyULNwdYTjMlxsmK62MxAXsway41cTI5p4m10T1oHXALheEQih/NW6Yxr9tIzVTwU=
Received: from BL0PR06MB4803.namprd06.prod.outlook.com (10.167.182.157) by BL0PR06MB4850.namprd06.prod.outlook.com (10.167.233.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.26; Thu, 8 Nov 2018 07:45:33 +0000
Received: from BL0PR06MB4803.namprd06.prod.outlook.com ([fe80::fc95:7a3a:36de:e498]) by BL0PR06MB4803.namprd06.prod.outlook.com ([fe80::fc95:7a3a:36de:e498%5]) with mapi id 15.20.1294.034; Thu, 8 Nov 2018 07:45:33 +0000
From: Karen O'Donoghue <odonoghue@isoc.org>
To: Warner Losh <imp@bsdimp.com>
CC: "hidinginthebbc@gmail.com" <hidinginthebbc@gmail.com>, "ntp@ietf.org" <ntp@ietf.org>, "eggert@cs.ucla.edu" <eggert@cs.ucla.edu>
Thread-Topic: [Ntp] Finding leap-seconds.list
Thread-Index: AQHUdrZzFWCO5qQ7gUWGpMGF5FVSCaVEmeQAgAAV04CAAGeAgIAAFpYAgAACJoCAAASmgIAAA2cAgAAJOACAAARpgIAAOv6A
Date: Thu, 08 Nov 2018 07:45:32 +0000
Message-ID: <BFE5458F-702E-406B-8C4B-45671CB371A1@isoc.org>
References: <5884DA3A-B95B-4D6B-9A31-E964CE4F02EF@gmail.com> <53bc1310-c198-557a-54ca-57b5b0af9bcb@meinberg.de> <AM6PR0602MB3733A11C62B7A0ED49F318B5FFC40@AM6PR0602MB3733.eurprd06.prod.outlook.com> <9A89609A-9A4E-41EB-A857-91252E5F6D04@gmail.com> <43c65279-12fa-4510-1d8f-b6e1b03caf7e@gmail.com> <CANCZdfpJZLEORhak2QWDuHgjrQ_UZzBNv4_RR9prDKU7qtZVHQ@mail.gmail.com> <1a897dcc-b89d-9365-104f-633798831331@gmail.com> <CANCZdfpp--enmBF4STBeuLsga9yOtd-Hvm-JdA_0QAgA6aUqFg@mail.gmail.com> <79e80621-8d7f-f7af-e52a-a436e00eb177@gmail.com> <CANCZdfo=zg3FpTZ4pv4-SUy=dD+02QELO15TVOx3ZP9yg2SKhA@mail.gmail.com>
In-Reply-To: <CANCZdfo=zg3FpTZ4pv4-SUy=dD+02QELO15TVOx3ZP9yg2SKhA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org;
x-originating-ip: [2001:67c:370:128:bcff:d77b:b3b3:7eb2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL0PR06MB4850; 6:4S0fnJu/ZcIMaRbjZ4R88JZu5UyXh9NXDUhFiNa1Tk2EbFG351ah+9Wg+IEtGUEpH61atlC+W+xFBYi5JLXb8I9JkC7N9YXPnczoBo2j2EsWsSSBPh13UPxY0ciDHPAz87UFuDszfvMHFV+XUucxMFcGvXXjZFIWWnggQp+m8rhgkvCGyU6S9L5SnnDgEmxdW+vRHte5AFwmbAi1oSpR2UjKuxnTLToDF8sCuONkHx8+0ip+q/1N/3YQrtG57RQYJgwbygJX3tamjXTz17K59S14vJRj624oEnyqDwrQi7s2weLo1PUPVNL1rj5lCTleNUGov5gcPymcfk3PBiopoGWyLUxLzVLHByT+dLppotIuCMtw9oEk6jFA2+lO0ivJrFTucJQZgA3+7LEjJ56iUuc2R5/Jz0oBu9bmQfkago1f+P2uILSfVKbWDrmra+iBGzRO4u4Bf4TJq8vzdv+HWA==; 5:RtJCgRpfnmigIcSrXrSkBqZ006qwh4kwwi0CuPkNBTwZSE2aLxUmpm/qMfKdVu0H4Chb/Koi5/nBP5fP3B7ZUrB7F4Bb8rdDa+2pk+YLabIWgx+oa2IDQpa2kKdjtG+aDXrIb0QilY+NmXYUzLLh2sshdwiytFUdvl7iaZf9xsU=; 7:QVCmO/zq7RUxZstHsWpIBG5HjUtoVpgum1rbuJs6D1FJxGdPTIm/fNVm8IBqfWC5UL1QBJDNyJb5f0fpuy7UH3nt92irXr4X2ToBNX6dRd84+CwTusEuO/RxoK7tGS4mKdySiH6X3RHPAowOVzU7aw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 80f5e31b-595a-4ed6-c235-08d6454e29d9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4850;
x-ms-traffictypediagnostic: BL0PR06MB4850:
x-microsoft-antispam-prvs: <BL0PR06MB4850F716729B7C1439420F84C2C50@BL0PR06MB4850.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(244540007438412)(85827821059158)(100405760836317)(158342451672863)(17755550239193)(4659246709749)(56005881305849)(11036507334643)(75325880899374)(270544422350281);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231382)(944501410)(4982022)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4850; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4850;
x-forefront-prvs: 0850800A29
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39850400004)(136003)(376002)(346002)(366004)(52314003)(252514010)(13464003)(199004)(189003)(46003)(256004)(14444005)(446003)(476003)(2616005)(486006)(186003)(53546011)(76176011)(6506007)(36756003)(229853002)(5024004)(6116002)(478600001)(2900100001)(6916009)(45080400002)(7736002)(2906002)(86362001)(25786009)(4326008)(5660300001)(39060400002)(11346002)(4001150100001)(53386004)(6436002)(8676002)(71190400001)(71200400001)(66574009)(6512007)(236005)(4744004)(105586002)(106356001)(53946003)(6306002)(54896002)(83716004)(82746002)(606006)(93886005)(99286004)(53936002)(316002)(102836004)(54906003)(14454004)(8936002)(81156014)(81166006)(97736004)(6486002)(6246003)(966005)(33656002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB4850; H:BL0PR06MB4803.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
x-microsoft-antispam-message-info: FMKwvGXwcGlfLugmlML/e3ohbCPU1ShdY4jToNNg+0GkQo3d5K/tbJzoGM6et2c2N4mcYPVqBn5SH3HGtUrEhizPBUB8+g8/Jijwemq4XYcdOYyG3NSf2+9tDskSE706pZ3gg0pRHBbgAtLb8ufWg95RTmYCGq6KN1EyUXZbQ06W28llGAA8aqYpiFNsUGt22mi3Z0IVhNp3OyN1ojqHVgq0PC97uje1DyMFeRHspb6pjdyWGd8eBmR7GzYFleeqXItpZ6EBsgP4GVrId9RrBLoifeU8CpIIFEL/bzluCPDvaeHFbhHaT6lCMWK7JE+Zu8FevsZ/JqG1gr/W9vaVmJm3JXQxYntr7+88vv95zLA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BFE5458F702E406B8C4B45671CB371A1isocorg_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 80f5e31b-595a-4ed6-c235-08d6454e29d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2018 07:45:32.9895 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4850
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/n8MADbuUE1WX1XxLJyAxama775w>
Subject: Re: [Ntp] Finding leap-seconds.list
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 07:45:43 -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 <imp@bsdimp.com<mailto:imp@bsdimp.com>> wrote:



On Wed, Nov 7, 2018 at 8:58 PM Thomas Peterson <hidinginthebbc@gmail.com<mailto:hidinginthebbc@gmail.com>> 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
FreeBSD 12.0         2018-12-01 (anticipated).


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 <hidinginthebbc@gmail.com<mailto:hidinginthebbc@gmail.com>> wrote:
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.

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.

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?

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


[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
> <hidinginthebbc@gmail.com<mailto:hidinginthebbc@gmail.com> <mailto:hidinginthebbc@gmail.com<mailto:hidinginthebbc@gmail.com>>> wrote:
>
>     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, tz@iana.org<mailto:tz@iana.org>
>     <mailto:tz@iana.org<mailto:tz@iana.org>>, pool@lists.ntp.org<mailto:pool@lists.ntp.org>
>     <mailto:pool@lists.ntp.org<mailto:pool@lists..ntp.org>>, freebsd-ports@lists.freebsd.org<mailto:freebsd-ports@lists.freebsd.org>
>     <mailto:freebsd-ports@lists.freebsd.org<mailto:freebsd-ports@lists.freebsd.org>>) 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 08/11/2018 01:28, Dieter Sibold wrote:
>>
>>
>>     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.
>>
>>>
>>>     --
>>>     Denis Reilly  |  Technical Lead  | denis.reilly@orolia.com<mailto:denis.reilly@orolia.com>
>>>     <mailto:denis.reilly@orolia.com<mailto:denis.reilly@orolia.com>> (585)321-5837
>>>
>>>     -----Original Message-----
>>>     From: ntp <ntp-bounces@ietf.org<mailto:ntp-bounces@ietf.org>> <mailto:ntp-bounces@ietf.org<mailto:ntp-bounces@ietf.org>>
>>>     On Behalf Of Martin Burnicki
>>>     Sent: Wednesday, November 07, 2018 1:00 PM
>>>     To: Thomas Peterson <hidinginthebbc@gmail..com<mailto:hidinginthebbc@gmail.com>>
>>>     <mailto:hidinginthebbc@gmail.com<mailto:hidinginthebbc@gmail.com>>; ntp@ietf.org<mailto:ntp@ietf.org>
>>>     <mailto:ntp@ietf.org<mailto:ntp@ietf.org>>
>>>     Cc: Paul Eggert <eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>> <mailto:eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>>
>>>     Subject: Re: [Ntp] Finding leap-seconds.list
>>>
>>>     Thomas Peterson 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
>>>>     https://www.ietf.org/timezones/data/leap-seconds.list<https://www.ietf..org/timezones/data/leap-seconds.list>, but for
>>>>     some participants of this working group appear unclear about.
>>>
>>>     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.
>>>
>>>>     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<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/
>>>>     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/>
>>>>     <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?
>>>>     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.
>>>
>>>     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: martin.burnicki@meinberg.de<mailto:martin..burnicki@meinberg.de>
>>>     <mailto:martin.burnicki@meinberg.de<mailto:martin.burnicki@meinberg.de>>
>>>     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.meinberg.de/> https://www.meinbergglobal.com<https://www.meinbergglobal.com/>
>>>     Training: https://www.meinberg.academy<https://www.meinberg.academy/>
>>>
>>>     _______________________________________________
>>>     ntp mailing list
>>>     ntp@ietf.org<mailto:ntp@ietf.org> <mailto:ntp@ietf.org<mailto:ntp@ietf.org>>
>>>     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.
>>>     _______________________________________________
>>>     ntp mailing list
>>>     ntp@ietf.org<mailto:ntp@ietf.org> <mailto:ntp@ietf.org<mailto:ntp@ietf.org>>
>>>     https://www.ietf.org/mailman/listinfo/ntp
>     _______________________________________________
>     ntp mailing list
>     ntp@ietf.org<mailto:ntp@ietf.org> <mailto:ntp@ietf.org<mailto:ntp@ietf.org>>
>     https://www.ietf.org/mailman/listinfo/ntp
>
_______________________________________________
ntp mailing list
ntp@ietf.org<mailto:ntp@ietf.org>
https://www.ietf.org/mailman/listinfo/ntp