IETF Logo Mail Archive

[Ntp] Antw: Re: Antw: Re: [EXT] Re: NTPv5 draft suggestion to move timescale offset into extension fields.

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Tue, 17 January 2023 12:51 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 32C4AC1782D6 for <ntp@ietfa.amsl.com>; Tue, 17 Jan 2023 04:51:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwujJ6hNE6IT for <ntp@ietfa.amsl.com>; Tue, 17 Jan 2023 04:51:28 -0800 (PST)
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 5144BC15170B for <ntp@ietf.org>; Tue, 17 Jan 2023 04:51:27 -0800 (PST)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3E47C6000053 for <ntp@ietf.org>; Tue, 17 Jan 2023 13:51:23 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx2.uni-regensburg.de (Postfix) with ESMTP id 1D0E0600004D for <ntp@ietf.org>; Tue, 17 Jan 2023 13:51:23 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 17 Jan 2023 13:51:23 +0100
Message-Id: <63C699C9020000A100051522@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.4.2
Date: Tue, 17 Jan 2023 13:51:21 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: david@venhoek.nl
Cc: "ntp@ietf.org" <ntp@ietf.org>, mlichvar@redhat.com
References: <CAPz_-SU7rctchBVvm59YAoEA7p8Or9aqdGovJ2E98Tp85jVsWQ@mail.gmail.com> <Y2jCtzeJZfz2daYJ@localhost> <CAPz_-SVkFZaycpimBGy-pZRgwxo9pdnrmh7QDd-=+qvXfdFKRw@mail.gmail.com> <63691D61020000A10004F69D@gwsmtp.uni-regensburg.de> <CAPz_-SWE0UxBoRe6Orr0-t7Mq7z5O-QnyGk+zBNDjDcTd5TxpQ@mail.gmail.com> <Y8UfskkHan7Te8dA@localhost> <CAPz_-SUvMH4DuQzjhFiAGm34v3UE89tb4UqJ=tB63taAK_jLCw@mail.gmail.com> <Y8aA97ioVN6n7/ai@localhost> <63C68CA5020000A10005150D@gwsmtp.uni-regensburg.de> <CAPz_-SUwp89zvP-GOxWtG7j2kdLWuLRBELU_dq3Teqkqqed2kw@mail.gmail.com>
In-Reply-To: <CAPz_-SUwp89zvP-GOxWtG7j2kdLWuLRBELU_dq3Teqkqqed2kw@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/E1O1FYO2ALefE13cAuJnav-NgMQ>
Subject: [Ntp] Antw: Re: Antw: Re: [EXT] Re: NTPv5 draft suggestion to move timescale offset into extension fields.
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 17 Jan 2023 12:51:32 -0000

>>> David Venhoek <david@venhoek.nl> schrieb am 17.01.2023 um 13:26 in Nachricht
<CAPz_-SUwp89zvP-GOxWtG7j2kdLWuLRBELU_dq3Teqkqqed2kw@mail.gmail.com>:
> The problem with TAI (or any other fixed timescale) for all time
> exchanges is that this forces every node to know that timescale.

Would it be much different from using arbitrary time-scales?

> However you then can run into the problem that it is not available to
> the system via any route, inhibiting any time exchange.

Well there would be still UTC for a while (for compatibility).

Regards,
Ulrich

> 
> On Tue, Jan 17, 2023 at 12:55 PM Ulrich Windl
> <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>
>> >>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 17.01.2023 um 12:05 in
>> Nachricht <Y8aA97ioVN6n7/ai@localhost>:
>>
>> ...
>> > What do others think?
>>
>> Actually I don't know, but it seems we need to support UTC for compatibility 
> with the past; otherwise I'd tend to suggest a radical approach:
>> Use TAI for time exchanges only, and insert a "time converter" between the 
> NTP clock model and the host clock model (bi-directional). So one could have 
> any type of local time one would like.
>>
>> Regards,
>> Ulrich
>>
>> >
>> > --
>> > Miroslav Lichvar
>> >
>> > _______________________________________________
>> > ntp mailing list
>> > ntp@ietf.org 
>> > https://www.ietf.org/mailman/listinfo/ntp 
>>
>>
>>
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email