Re: [Ntp] WGLC - draft-ietf-ntp-ntpv5-requirements

Steven Sommars <> Thu, 14 December 2023 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6BE6C14F74E for <>; Wed, 13 Dec 2023 16:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qErPXvOHO0BI for <>; Wed, 13 Dec 2023 16:46:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (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 (Postfix) with ESMTPS id 6D63CC14F747 for <>; Wed, 13 Dec 2023 16:46:01 -0800 (PST)
Received: by with SMTP id 2adb3069b0e04-50e0daa57b3so1774264e87.3 for <>; Wed, 13 Dec 2023 16:46:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702514759; x=1703119559;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZnUCriVNDg0JDlYS4KH4ERuRiyJMJREgRcFQtbn9ekY=; b=mczfTGJBC22kzhY9jW8ZXBZVb2D02d6b7Wilx8vsXkpWIftTEGacueGCcZYsc8rh6d zyE+Hi0Vvxi4MTqbUO4C0nl4GsvK/fNOxl29jjBKv7YrTNW7NhL0+i1Z67Zeqd9cmmr2 Kw55ALvH8LUVMlAbKx1CRWUPO3uDqJQ5aeiA8Zu7rYilxFt2tuBlvddjczv5Uj8Evq5B xlRv3GNSBryG91TSs4SkRaOwqjCEUOUm7RtbAk8dPXYXLiVS9/cHclacnJZmgZc2hrG3 JFCZux6hcOGZV9kZF/RKjZX3wU6G+rhaT4k2wEG6Q6P5HwJ24ME51jZPN7brdlOwO0CE BGoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702514759; x=1703119559; h=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=ZnUCriVNDg0JDlYS4KH4ERuRiyJMJREgRcFQtbn9ekY=; b=g9oOBfd94W9RcbIpWZZL13BlvElNQ8Lhjtc4593K/zdG3J/zDs/qRdzSlCz1KGz1+B VJGnkOafbMghVbopHQ359BMH8F9tlYIpIjZm0hV7hcfH/btpdMtujtqc874wutVlLJkK 53eiIXaqXhBNnvfxC66GQYRQwQ40s2jFsR0/hPmQz0RD/1AjcIIT/h49wcr+weO0veR4 20f4lNWTpLVRg6C/yux4mj26yFB0n+CG0A+I8gy3o57DHYyiBwE64WdcHO/apZgAB9xo ANdAJGEXWBJXa3wlnq2SES+lW7n0HpUUQyblfevN2aJgVKPLdB3MlETqUTi0kZLzDrVl dYZg==
X-Gm-Message-State: AOJu0YyQtYRtIuxFm4jxJFQMhiJuWFW4EuOj9yVrOmMJdn3LPjFga3Ku z88boRXDcdCkfc8aFGz/2Ym0hHEVGobKHRAQIQgkCG4pUI133Cqq
X-Google-Smtp-Source: AGHT+IFd/z4Wtt1KOu4lwuh8mvw9OLue1y2Lgj3zIQd6gSG9+kmSdK9XrJuCR9YuKXjphcP2KhjxdmmHsYwnCMbgVl8=
X-Received: by 2002:a05:6512:3708:b0:50c:a91:6189 with SMTP id z8-20020a056512370800b0050c0a916189mr2314676lfr.49.1702514759321; Wed, 13 Dec 2023 16:45:59 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Steven Sommars <>
Date: Wed, 13 Dec 2023 18:45:59 -0600
Message-ID: <>
To: Karen ODonoghue <>
Content-Type: multipart/alternative; boundary="000000000000744cdd060c6d9b0b"
Archived-At: <>
Subject: Re: [Ntp] WGLC - draft-ietf-ntp-ntpv5-requirements
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Dec 2023 00:46:05 -0000

My interpretation of the draft NTPv5 requirements is that there are
intentionally no NTPv4 compatibility requirements.
E.g., the base payload length may not be 48 bytes, the messages may differ
from NTPv4.
If this is not the intention, the draft should be updated accordingly.  If
no consensus can be reached the NTPv5 requirements should state this
clearly and work on the NTP protocol itself should be paused.

Section 3.  NTP is considered by some to be a hostile protocol. As a result
there has been  intentional blockage on some paths.
NTP Filtering (Delay & Blockage) in the Internet

4.4 Timescales
UTC is neither linear nor monotonic.
NTPv4 has insufficient resolution  today for root dispersion and root

4.5 Leap seconds.

Smeared leap seconds were and remain a workaround for various real-world
implementation issues.
I believe that much of this mechanisms success comes from the ease of
deployment (unmodified clients, changes are limited to the server).   This
section suggests that the 2016-era leap second smearing would be
incompatible with NTPv5.
If there is another leap second, it seems to me more likely that admins
will use the 2016-style leap second smearing.

The 2016-style smearing may result in less accurate time transfer.

Per Wikipedia <>
" in November 2022, at the 27th General Conference on Weights and Measures,
it was decided to abandon the leap second by or before 2035"     It seems
that by the time NTPV5 becomes final, plus client and server
implementations are deployed, it will likely be too late for a new leap
second smearing mechanism to be used.