IETF Logo Mail Archive

Re: [Ntp] Consensus call: NTPv5 and leap second smearing

David Venhoek <david@venhoek.nl> Fri, 30 June 2023 09:09 UTC

Return-Path: <david@venhoek.nl>
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 49463C15108D for <ntp@ietfa.amsl.com>; Fri, 30 Jun 2023 02:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venhoek-nl.20221208.gappssmtp.com
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 hNsD3ZuhUDQ4 for <ntp@ietfa.amsl.com>; Fri, 30 Jun 2023 02:09:23 -0700 (PDT)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3EBC14CE47 for <ntp@ietf.org>; Fri, 30 Jun 2023 02:09:22 -0700 (PDT)
Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3a1e6022b93so1149371b6e.1 for <ntp@ietf.org>; Fri, 30 Jun 2023 02:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venhoek-nl.20221208.gappssmtp.com; s=20221208; t=1688116162; x=1690708162; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qR/xaBqj02fk4PVCR8aTpNx5eaTD0B0sssaJL+ETEl8=; b=5UPLj2BF42G9+hNfZWZKtSirlz7xon3DN/ZljpeKhB8Hjx5dxl26TV1Du5jCtjJWJc bq0EQ8kOERdLTYiXDhFAh84RQ006tSuePFZYmfTAlrMpJOwiNdgPEPTiVDveM4MhI7vY +xd/f4rlXanAYMPNLb12suylJcZ7DE9URnTP831an326qB74DHlCfL9pgzl7jBcpdqkx OIfXI++6i+GssUOPVqnfDl22DatQJFGO1OjCIGeVXZNicw8/iexGrE+rtyPx+j9qiQQQ 4aBqJNhIypxJwW1+7pNDwBNtXuhXawBb8wSfMmrya1wVSKj09vAbrHyj1EqgqOfB3pg6 Z8uQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688116162; x=1690708162; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qR/xaBqj02fk4PVCR8aTpNx5eaTD0B0sssaJL+ETEl8=; b=fRYCXsrA3ucbPudMEc/XOexjBAYLZVkKFljRueGyL/z9kloUGDMT6AP1N/PoOBrbIc xkCreT+OdRflIx8FllHYRCDcJbkAIa8RPto0u+2smntjTj89tryhBrxOLioqu4AYepcM 85/JgegV41ifZAXxkE/uxbzpO3ofcvCJWd7CZCxk9/pMlcCPX+QphcV61RDUFz+yQcxf GCPa1q+BdBuzCANY40j5x+7l6/E0yEzugtUWVykrLr5XKMCM4sOirnuHX89923/HRlk1 Uw3WQ4+T2zdw0jrSnToHSE7tj5Do3o7akQSIQNuQLcCqqtvVZtHXhvBQ+Cn+BH9d6a0g KIlg==
X-Gm-Message-State: AC+VfDz9TXxoIaI0WDsw7afrOMmCg3oDMsVYtReFCd8qzixRNw7QZh9O 0Wyxw06XfuuN5DS5St8agkCz2mqqBwfQnh2bZFpVgQ==
X-Google-Smtp-Source: ACHHUZ4/jI3/SDUYBahKmeQkJK4VzNlk2mYEvjR4oV+uzBbc3l+PwUY0O7rPvBrdOeyunRWc9/Vi0L4pb4jc3y7QOqk=
X-Received: by 2002:a05:6808:2009:b0:3a1:cd86:9e70 with SMTP id q9-20020a056808200900b003a1cd869e70mr2361392oiw.22.1688116161916; Fri, 30 Jun 2023 02:09:21 -0700 (PDT)
MIME-Version: 1.0
References: <29343948-036E-4514-8B42-689C19A61813@gmail.com> <a8671454-775c-014b-12df-66dffbe01e39@libertysys.com.au>
In-Reply-To: <a8671454-775c-014b-12df-66dffbe01e39@libertysys.com.au>
From: David Venhoek <david@venhoek.nl>
Date: Fri, 30 Jun 2023 11:09:11 +0200
Message-ID: <CAPz_-SXEqSWvxAZB+qPix31fF077Po3C9XkMzTTLeOTAr44uQA@mail.gmail.com>
To: Paul Gear <ntp=40libertysys.com.au@dmarc.ietf.org>
Cc: ntp@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/16qKHws5Zse7TCBdcmKPCxqTA9s>
Subject: Re: [Ntp] Consensus call: NTPv5 and leap second smearing
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: Fri, 30 Jun 2023 09:09:24 -0000

I wholly concur with Paul's view on this.

Kind regards,
David Venhoek

On Thu, Jun 29, 2023 at 2:54 AM Paul Gear
<ntp=40libertysys.com.au@dmarc.ietf.org> wrote:
>
> On 29/6/23 05:55, Dieter Sibold wrote:
>
> Dear all,
>
> at IETF 116 we decided to have two consensus calls regarding the content of the NTPv5 requirement draft. These are consensus calls that we would like to conduct to help progress the NTPv5 requirements document (https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/). Both consensus calls will run until July 21st 2023 and will be discussed at the next NTP wg meeting at IETF 117 in San Francisco.
>
> The second consensus call:
>
> Regarding leap second smearing:
>
> Currently, the NTPv5 requirement draft states that NTP servers should not apply leap second smearing to transmitted timestamps. Shall NTPv5 support leap second smearing? If yes, shall the NTP server apply leap smearing to the transmitted timestamps or otherwise shall the client perform leap second smearing?
>
>
> The reason smearing gets used under current NTP versions is because the people using it have large-scale issues with timestamp-sensitive software, and it's more efficient to implement the smearing on the servers than on the clients, which can be orders of magnitude greater in terms of scale.  If we prevent this, we will only hinder the adoption of newer versions.
>
> So, yes, NTPv5 should support leap second smearing, and yes, it should be possible to apply that smearing to the transmitted timestamps so that clients don't have to be configured for it.
>
> My suggestion in terms of BCP 14 (RFC 2119/8174) terminology is that NTPv5:
>
> MUST support sending non-leap-smeared timestamps
> MAY support sending leap-smeared timestamps
> SHOULD send non-leap-smeared timestamps by default
> if it sends leap-smeared timestamps MUST provide indication (via a flag or extension) that they are in use
> if it sends leap-smeared timestamps, SHOULD send indication (via an extension?) of the current UTC-to-smeared-time offset
>
> Regards,
> Paul
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email