IETF Logo Mail Archive

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

Miroslav Lichvar <mlichvar@redhat.com> Wed, 20 October 2021 07:15 UTC

Return-Path: <mlichvar@redhat.com>
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 CAAD13A0DBD for <ntp@ietfa.amsl.com>; Wed, 20 Oct 2021 00:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 pNpUniGm4Ggr for <ntp@ietfa.amsl.com>; Wed, 20 Oct 2021 00:15:08 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 4674F3A0DBA for <ntp@ietf.org>; Wed, 20 Oct 2021 00:15:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634714106; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5Dww/p73iT4YHkqIxbW4ZfHa/MHQFB4TrgI+wJU2kB8=; b=WL8WcuggUEmTG9UX3YCeWvlonmlK0viPIOJVZTkixxE4O7/SGK5Yn4dxBjEXqnj5o/Z+ZA a9z47qUrKmQCMqy91UXSRFs6JfW6XcO+Jyu8UpzKCKIFuy9mrFALP+qSb23Pu6T9we6Zvd uihRDQTKFcA+HJ20LIBXBr1q/AGwBL8=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-10-hsTzqsyTP-6Y94aRlJ35dg-1; Wed, 20 Oct 2021 03:15:01 -0400
X-MC-Unique: hsTzqsyTP-6Y94aRlJ35dg-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 88BEADF8A0; Wed, 20 Oct 2021 07:14:59 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CDFF8641A7; Wed, 20 Oct 2021 07:14:54 +0000 (UTC)
Date: Wed, 20 Oct 2021 09:14:53 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Warner Losh <imp@bsdimp.com>
Cc: Danny Mayer <mayer@pdmconsulting.net>, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, james.ietf@gmail.com, "ntp@ietf.org" <ntp@ietf.org>, Doug Arnold <doug.arnold@meinberg-usa.com>
Message-ID: <YW/B7bzeJEpeaQJm@localhost>
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>
MIME-Version: 1.0
In-Reply-To: <CANCZdfrN6bjYezbir_VhLpcxosHQ35RHVwMs1fwvXBOcBL2QYQ@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/T7szsU5Xl3pX3BQ_yVJbWnRpVN4>
Subject: Re: [Ntp] 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:15:18 -0000

On Tue, Oct 19, 2021 at 09:26:28AM -0600, Warner Losh wrote:
> 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...

TAI-based servers can report the offset correctly at all times, so
clients can reliably reconstruct TAI reliably from the UTC timestamp
and the offset, but if they synchronize the clock in TAI and have an
option to request timestamps in TAI, they should probably do that
instead.

I agree it's important to define where exactly the leap is expected.
For easier implementation and compatibility with NTPv4, it might make
sense to specify the "nanokernel" leap used in current systems.

UTC-based servers will need to indicate "unknown" offset around the
leap to avoid jumps in the reconstructed TAI.

-- 
Miroslav Lichvar

v2.23.0 | Report a Bug | By Email