Re: [Ntp] Antw: [EXT] Re: Timescales

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 10 December 2020 06:59 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 1D2D03A08B1 for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 22:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Mo0nlFQ9YHfk for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 22:59:47 -0800 (PST)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46AE3A08AE for <ntp@ietf.org>; Wed, 9 Dec 2020 22:59:47 -0800 (PST)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 001C8600004F for <ntp@ietf.org>; Thu, 10 Dec 2020 07:59:43 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id DABB5600004E for <ntp@ietf.org>; Thu, 10 Dec 2020 07:59:43 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 10 Dec 2020 07:59:43 +0100
Message-Id: <5FD1C75D020000A10003D6FF@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.0
Date: Thu, 10 Dec 2020 07:59:41 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: mlichvar@redhat.com
Cc: "ntp@ietf.org" <ntp@ietf.org>, Hal Murray <hmurray@megapathdsl.net>
References: <20201209101830.7CB0240605C@ip-64-139-1-69.sjc.megapath.net> <20201209113003.GA2352378@localhost> <5FD0D13C020000A10003D6CB@gwsmtp.uni-regensburg.de> <20201209134612.GC2352378@localhost>
In-Reply-To: <20201209134612.GC2352378@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/4lzzVkdKkNd812buF_se-AJU1hE>
Subject: Re: [Ntp] Antw: [EXT] Re: Timescales
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, 10 Dec 2020 06:59:50 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 09.12.2020 um 14:46 in
Nachricht <20201209134612.GC2352378@localhost>:
> On Wed, Dec 09, 2020 at 02:29:32PM +0100, Ulrich Windl wrote:
>> However you could see the leap indication flag also as "leap confirmation"
>> flag (actually there will be a leap event). With only DCF‑77 clocks this 
> could
>> be a problem. As said earlier, it would be best if NTP could reliably 
> transfer
>> the leapsecond table, or at least the relevant part of it to make clients 
> know
>> in advance that and when a leap event is scheduled.
> 
> There is the tzdist (RFC7808) protocol designed for that.
> 
> NTP could distribute a leap‑second table (it already did it with
> Autokey, right?), but isn't NTP about distributing current time,
> rather than reconstructing time in the past or future?

Hi!

You all seem to have missed my point: In the recent past there was a lot of
discussion and confusion what the LI (Leap Indicator) means:
Leap second today, leap second at the end of the month, leap second soon. So
having the definite time of the next leap event would all make this easier.
Actually it could make the LI even obsolete.

Regards,
Ulrich

> 
> ‑‑ 
> Miroslav Lichvar