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

Dieter Sibold <> Mon, 14 June 2021 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECF5B3A2816 for <>; Mon, 14 Jun 2021 08:38:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nGHF7Xs0pDdA for <>; Mon, 14 Jun 2021 08:38:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FF1A3A284E for <>; Mon, 14 Jun 2021 08:38:32 -0700 (PDT)
Received: by with SMTP id t4-20020a1c77040000b029019d22d84ebdso13389778wmi.3 for <>; Mon, 14 Jun 2021 08:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=0Z+Xb/2bT81d2YqaKjOd22XRFLDkqHsVT8Y5WiK/KOM=; b=Eis60ZAP2e2MPMaf1dDBha/mO0FuuhEvQUGq7MShx8LnB5PT1qKv0Gn02sHKK8GnQm bPFlAgfurMR72cKk3O/xl7InVgK+f2UOl65PPcht7gp39h1qFskckukU6JUETcpo5j9v 13KovWA3cXX9C/uwD6vNElpjNLZTyYm1IhHdrnJCDkA5sZUsi4fGCOD00+rDuY6wYsUz yQQL9+QUWJb8zol29JImYmRCp7xFWYba3JZSmLiW/0sb5UpwBImBxRNgsO4REfI60h5J 0VpoQt15VXjslWCusMGYVS2+L7z9GCHZqen1kJTr8tN0Y58JTRMYaQkIk8wxl6R5esWh h9CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=0Z+Xb/2bT81d2YqaKjOd22XRFLDkqHsVT8Y5WiK/KOM=; b=UFumphLY4EbRYhO1cd1NLVIiuift+O8kIbbqreGvTC0jw3CdFKZY0kZxXL5o7wXk+5 Y752xwqd9a0P9QbZxdmB0YMakHpros3b2MO9yCMkezLSXJbG9sEfy5V3eqN1MSutIRhy OKjsdc8DZz0sn08bbkTW5BrJ9nZ264RW7gVaaeJYd5qkir+alwJniMj4847/wQlrJpHy Y4lR2Dhp7AaucQsC0d0VNFoFzoqRaNfT6YcOo+KfxMI5GfN+8rOgNJjZY99pwkzHRPO8 HKGw49ieA3QH56ZGx7UYIWwnLhzc5YGsAIsAC6aUKpGwS2qP5pyZK+IrVwubeN2gxaYr 9YOw==
X-Gm-Message-State: AOAM531YjZKkjiHJJnkd7GsWeUSmmlhmMjWZbCX+x1K1AEPyACZp5SYS SDIDONH8Bee0Am4QBAmKc0/YHbUaqb0=
X-Google-Smtp-Source: ABdhPJyKS9DRUcWkEovXBauSDcjMX4GKmij3VtafxKm+PVmJRbtrEBGbthGmWTDen4A/tBf/y/xS/w==
X-Received: by 2002:a1c:e90d:: with SMTP id q13mr17120917wmc.163.1623685109194; Mon, 14 Jun 2021 08:38:29 -0700 (PDT)
Received: from [] ( [2003:d1:7f1e:1ffc:3180:b906:830d:43c5]) by with ESMTPSA id f18sm13351241wmj.13.2021. for <> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Jun 2021 08:38:28 -0700 (PDT)
From: Dieter Sibold <>
Date: Mon, 14 Jun 2021 17:38:26 +0200
X-Mailer: MailMate (1.14r5807)
Message-ID: <>
In-Reply-To: <YMc3qU1UHSvQT/Gu@localhost>
References: <20210522183113.7ovb2crqg7h5q6fs@de970ef05f79> <YMc3qU1UHSvQT/Gu@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] [ New Version Notification for draft-gruessing-ntp-ntpv5-requirements-02.txt]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Jun 2021 15:38:37 -0000

On 14 Jun 2021, at 13:04, Miroslav Lichvar wrote:

> On Sat, May 22, 2021 at 06:31:13PM +0000, James wrote:
>> URL:  
>> Status:
>> Htmlized:
>> Diff: 
> I'd like to see this draft considered for adoption. We need to agree
> on the NTPv5 requirements before we can discuss the details of the
> actual protocol.
> I have few comments on some specific parts of the document:
> - "The specification MUST have support for servers to notify clients
>    that the service is unavailable, and clients MUST have clearly
>    defined behaviours honouring this signalling."
>   This looks like a good goal but I suspect we may not be able to
>   define a useful behavior for an unauthenticated context.
> - "Leap second smearing SHOULD NOT be part of the wire specification"
>   I think the protocol needs to have some way to indicate that the
>   server has leap smearing enabled. Servers implementing leap smear,
>   but clients not knowing about it (e.g. using its own leap second
>   source) is a major concern in some environments.

I would prefer that leap smearing is processed on the client side only. We are going to specify the version 5. This would make the specification much cleaner and would minimize the risk of misbehavior during leap second events in infrastructures where leap smearing might be needed.

In case of NTPv4 clients the server might respond with NTPv4 packets and might also do server-side leap-smearing. But a NTPv5 client can do it itself.

> - "Encryption and authentication MUST be provided by the protocol
>    specification as a default"
>   It's not clear to me what the default means here. That it is enabled
>   by default in all implementations that support it?
> -- 
> Miroslav Lichvar
> _______________________________________________
> ntp mailing list