Re: [Ntp] NTPv5 draft

Warner Losh <imp@bsdimp.com> Mon, 07 December 2020 20:06 UTC

Return-Path: <wlosh@bsdimp.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 AF36F3A083F for <ntp@ietfa.amsl.com>; Mon, 7 Dec 2020 12:06:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bsdimp-com.20150623.gappssmtp.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 k_F5NFuY9YEn for <ntp@ietfa.amsl.com>; Mon, 7 Dec 2020 12:06:53 -0800 (PST)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9A63A083B for <ntp@ietf.org>; Mon, 7 Dec 2020 12:06:53 -0800 (PST)
Received: by mail-qv1-xf32.google.com with SMTP id 62so7127965qva.11 for <ntp@ietf.org>; Mon, 07 Dec 2020 12:06:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ILQstygrPrycmN8BB01aIYr25VuVwm7as4Axt1mxS4=; b=06yD7VNDwYy21QJd8dyvJijdPBTNQ1vqlCogyyOzB/0tZK+IPMBp6KjMB9ky+jHVVM g67gfBGpAIBGnHRTHNBkX2W8HJe+TpOGQ8pbrAfGUFsVzlhYjnQFmeYdm55R0fdn6qRo lqPnBaV2mXfr686zIcYdmtd4Ken4yN/UXeqSB0r5XIvvbYyLLfxXNmD8xqjBt87lysJ0 6Pj0w+XmDRFfISH+QmG26NoRcwcZEa7se4+IOt0k7VhhKKnAkpjMKr/ywV39KZS9pqlM fMoC0Yq0nqa15cqXK02HCr6jUxHQ18cvPb3zRvvb3mRC004z7S/WIQM9ZQ2wjp3R6Ttq KQow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6ILQstygrPrycmN8BB01aIYr25VuVwm7as4Axt1mxS4=; b=Eqk+kSYOl4PgQoU7MAAuG2cdr0zgSE5IpWXlVXby3bqvLaJBM7vQR5s6DamkXPVdwt qOpG6NFc/ardsMB12B9X16ydjWJiMz+WBVQQbNaEyymAz3WqFmxKrZ16mwZvUlvtGp1T a1sFiQFzzANm0yRNlrKiTfoUCprKVbGa9tAkLwzdi2bX2VCrSX2RvbcyMDJ8vAnW/oE6 gt+3ZQSCmsHvecmSTcLLe8gLVp2U7MQ6xT7dy52nnTeccTaSrKcZd2nzktwPP0v7MC2X ymtbxh7mwydGxieeug047Q3oTn5zWvnxsxSrCeB2qGPE7fuPDIAq81rfTA6Nyc1AUoSR 4iTw==
X-Gm-Message-State: AOAM532HLkc6bRulbJrUTTHqvZsmcKrtIbudM7SXw/OYx2jt8YUTwFE/ a72nMX9B/zbfE5ni+ipf76M4A3UUVYg7bY+KhksQpw65BoOb/Q==
X-Google-Smtp-Source: ABdhPJymFMCZUcsfo4YmhU/pDjkVyRru21FfDe7hI+EF/orm5V0gIpKsnQm12dAS9ZfaxVGnKwmbiYbasmxbXYBaGEk=
X-Received: by 2002:a0c:bf0f:: with SMTP id m15mr23009366qvi.23.1607371612451; Mon, 07 Dec 2020 12:06:52 -0800 (PST)
MIME-Version: 1.0
References: <20201207191229.8F2C940605C@ip-64-139-1-69.sjc.megapath.net>
In-Reply-To: <20201207191229.8F2C940605C@ip-64-139-1-69.sjc.megapath.net>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 07 Dec 2020 13:06:41 -0700
Message-ID: <CANCZdfqJxOhPfopd7xZK7wmxc17H8UNxntyK5KXZuoB9dKWgBg@mail.gmail.com>
To: Hal Murray <hmurray@megapathdsl.net>
Cc: NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fb92db05b5e55dfd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/4ZTEioS1vWaSIixNg5XbMIXw7AM>
Subject: Re: [Ntp] NTPv5 draft
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Mon, 07 Dec 2020 20:06:56 -0000

On Mon, Dec 7, 2020 at 12:12 PM Hal Murray <hmurray@megapathdsl.net> wrote:

>
> > But much of that info need not be at the lowest-level time authentication
> > bootstrapping since there's overlap with other areas and services (the tz
> > database, for example).
>
> I think an RFC for NTPv5 should collect things like that.  The particular
> one
> that sentence brings up is leap-seconds.
>
> It's a long way from Paris to my desktop.  I don't thing an RFC has to
> totally
> solve that particular problem, but if it doesn't provide a good solution,
> it
> should have a section that describes the problem, explains what it does
> provide and what it expects some part of the environment to provide.
>

For leap seconds in particular, whatever solution you come up with has to
cope with 'late' discovery of leap seconds in a way that's at least
predictable, even if there's uncertainty until you have final knowledge.
The problem need not be solved entirely, but some reasonable bounds can be
used so the 'typical' error from leap seconds falls within those bounds as
an 'ordinary error' to the largest degree possible.

Warner