Re: [Ntp] NTP Extensions (was Re: Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard)

Watson Ladd <> Wed, 19 February 2020 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E205612084E for <>; Wed, 19 Feb 2020 13:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OBSY0DzUzkMv for <>; Wed, 19 Feb 2020 13:59:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A6D1120837 for <>; Wed, 19 Feb 2020 13:59:31 -0800 (PST)
Received: by with SMTP id d9so1401023qte.12 for <>; Wed, 19 Feb 2020 13:59:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Fu+grmu8e+WGXueG36CUsxn6EgaWvdpnzZfYS2W3D4=; b=kA2yUJrBP5Wuw/83JmZMFAQefP2OUkdy8MLxaw9SBY/8kh0ks3SEMVqgUUAmyPDlp0 V+ktOF9iEbO65r4EJ04ya0Hr4cB2inEYm8fdf4MhS1FBqD5gLmyEIbfWj/Thw6ro2Wb2 xJzq26cw0fQtnkiiF0aZXEhd831hJd/cgBZPs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Fu+grmu8e+WGXueG36CUsxn6EgaWvdpnzZfYS2W3D4=; b=G48+4Wbo0dn+x3yr6MfiRgkYg5LSKjadCwksMpdmG4qKiSJW+PJ7Sh0S6JV+2y5eDm Xk4TuOMDNdzy6D8mYQqk/yZLk2XQ+eLNyt0ptTPCuXN9665517nG/kFOjw4q00l9tXoJ Dw5E8nNIjcAUkTQ2XwmBV9FPvG2GUmxjsPg6WELkuNbopz5+sYKHlg69hVZuaWi1xj+e RkpngzaYkWaTupdZHzip5EzNCtuJndrcUVNVpGGEiFysnLC+CLOA7GBtFzoK3BmMge3P vB7w7x5JhrmZKvYGU2+Qz7OjT0RiT/8/colnqL89NQY6k2UTyK4desFUlI/Zq+DkOfg2 ZNIw==
X-Gm-Message-State: APjAAAVymKlh4AcOw41WxNlnYiuV2rlGmTH5F+aYQ3AhUrriAy72NE0v A6K7MaeL5RdTcGpGpNSQsw5l3Oyv9y+NYnvCPet1cLojrsM=
X-Google-Smtp-Source: APXvYqz4biLNVGVvsQaoS9kAr3pI0VmkgwLtJn4IvawLgSfXAlj3/Y84R7x6c2kxcqk+tMBh4Nw5MTQoMRvSh/F+xlQ=
X-Received: by 2002:ac8:3418:: with SMTP id u24mr23569083qtb.87.1582149570043; Wed, 19 Feb 2020 13:59:30 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Wed, 19 Feb 2020 13:59:19 -0800
Message-ID: <>
To: Harlan Stenn <>
Cc: NTP WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Ntp] NTP Extensions (was Re: Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Feb 2020 21:59:33 -0000

On Wed, Feb 19, 2020 at 1:33 PM Harlan Stenn <> wrote:
> Except that we did discuss this, years ago, and there was a meeting with
> me and Karen and I forget who else where we specifically said that
> 0xnn04 was already allocated for NTS.  I've long been saying we need a
> way to make progress with EF proposals that does not cause collisions
> between inplementations and avoids flag days.  Furthermore, I told Karen
> that the NTP Project was using 0xNN0[5-9] for other proposals and that
> with no progress on changing the way the NTP Extension Field IANA
> registry was being managed, that 1) the NTP Project has a chalkboard
> that we're using for this purpose, and 2) if anybody wants to work on an
> EF they should just let me know.

The way to achieve this is to make an experimental/private use range
for the registry. The registry is currently IETF review, which is
annoying: it's big enough to be Specification Required unless
proposals take large chunks of the range. It's not impossible to
change this with WG consensus.

As for avoiding flag days, early drafts are going to evolve, breaking
backwards compatibility anyway. I've always emphasized that we are
going to have breaking changes in our NTP service until the draft
stabilizes, I don't see how we can get any sort of experimental
deployment unless we're willing to break the toys. (And no, they don't
get to keep the pieces). One solution, copying from the TLS WG, is to
have draft version numbers in the ordinary version negotiation
mechanism, but that's not as suitable for an extension field.

We discussed a potential early allocation request at the virtual
interim that would give us plenty of time to have implementations
ready before RFC. There is no reason we can't all have implementations
and deployments supporting the final RFC version and numbers when they
come out.