IETF Logo Mail Archive

[Ntp] Antw: Re: Antw: [EXT] Re: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Wed, 20 October 2021 07:22 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 E61D83A0DCE for <ntp@ietfa.amsl.com>; Wed, 20 Oct 2021 00:22:12 -0700 (PDT)
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 YSldIo-G6d4T for <ntp@ietfa.amsl.com>; Wed, 20 Oct 2021 00:22:08 -0700 (PDT)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf8]) (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 6423A3A0DCB for <ntp@ietf.org>; Wed, 20 Oct 2021 00:22:08 -0700 (PDT)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6B3366000050 for <ntp@ietf.org>; Wed, 20 Oct 2021 09:22:04 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx2.uni-regensburg.de (Postfix) with ESMTP id 50FB1600004D for <ntp@ietf.org>; Wed, 20 Oct 2021 09:22:04 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 20 Oct 2021 09:22:04 +0200
Message-Id: <616FC39A020000A100044A06@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Wed, 20 Oct 2021 09:22:02 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: imp@bsdimp.com
Cc: james.ietf@gmail.com, "ntp@ietf.org" <ntp@ietf.org>, doug.arnold@meinberg-usa.com
References: <163386015957.12424.6997038478834885480@ietfa.amsl.com> <CAO+dDx=6baLhf9LwSMvR1F0ieuLO6NXmExYLDvcCF2tgchHs8w@mail.gmail.com> <DB8PR02MB5772AC97BFE2D7C1139EFDC0CFB89@DB8PR02MB5772.eurprd02.prod.outlook.com> <E469D9A7-7445-49D9-A8A2-82BA7BF1FA27@gmail.com> <YW2FvUiaHC/hbxkG@localhost> <616E7B69020000A10004491E@gwsmtp.uni-regensburg.de> <7f975043-7577-fd47-b5fb-f48e579828db@pdmconsulting.net> <CANCZdfrN6bjYezbir_VhLpcxosHQ35RHVwMs1fwvXBOcBL2QYQ@mail.gmail.com>
In-Reply-To: <CANCZdfrN6bjYezbir_VhLpcxosHQ35RHVwMs1fwvXBOcBL2QYQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/MJoZx_TsxdTO5sQuGThUjimtbEE>
Subject: [Ntp] Antw: Re: Antw: [EXT] Re: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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: Wed, 20 Oct 2021 07:22:13 -0000

>>> Warner Losh <imp@bsdimp.com> schrieb am 19.10.2021 um 17:26 in Nachricht
<CANCZdfrN6bjYezbir_VhLpcxosHQ35RHVwMs1fwvXBOcBL2QYQ@mail.gmail.com>:
> On Tue, Oct 19, 2021 at 9:18 AM Danny Mayer <mayer@pdmconsulting.net> wrote:
> 
>>
>> On 10/19/21 4:01 AM, Ulrich Windl wrote:
>> >
>> > Same for UTC vs TAI.
>> > I thing the TAI offset (whole seconds) should be part of every NTPv5
>> timing packet. So we can keep the old timestamp format while providing TAI.
>> > Maybe NTPv6 will demand that TAI should be the new time base. Still we
>> would need the offset to provide UTC and similar.
>> >
>> My proposal for an additional field includes the total number of
>> leapseconds added to TAI. You can then use this number to calculate the
>> TAI time from the UTC timestamps sent. A zero value for the count would
>> indicate the server doesn't know.
>>
> 
> Is that field signed or unsigned?  How large is it?
> 
> Personally, I'd make it a signed 16 bits and have 0x8000 indicating unknown.
> We believe today it will always be a positive number that only ever
> increases.
> However, recent rotation data says that weird short term things can happen
> even if we know the long term trend is always increasing and it would be a
> cheap way to hedge bets.
> 
> But even an 8 bit unsigned field with 0 meaning unknown is a huge
> improvement.
> 
> Be sure to have this field be well defined near leap seconds though. IIRC,
> the number should increment at the start of the leap second in UTC time,
> but I've not thought that through completely and since all simple things
> with leapseconds are harder than you think, best to be clear so everyone
> knows and any 'simple' mistakes are caught in review :) Having it only
> be approximate near the leap second would be a really really bad
> idea... Better to say '0' 30s either side of a leap second than to have
> it be broadcast incorrectly for a few seconds after...

Spontaneous idea: Why not have a triple (ToLS, c_offs, n_offs) where "ToLS" is the "Time of Leapsecond", "c_offs" is the current TAI offset, while "n_offs" is the next offset.
So the offset would indicate the type of leap event, and ToLS would indicate when that would happen (in TAI time). That would also allow a proper leap announcement.

Regards,
Ulrich

> 
> Warner

v2.23.0 | Report a Bug | By Email