Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt

Hal Murray <halmurray@sonic.net> Mon, 04 December 2023 00:57 UTC

Return-Path: <halmurray@sonic.net>
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 6AD48C14CF0C for <ntp@ietfa.amsl.com>; Sun, 3 Dec 2023 16:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 ZkY-0Nyg8i8x for <ntp@ietfa.amsl.com>; Sun, 3 Dec 2023 16:57:38 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 19E45C14CEFF for <ntp@ietf.org>; Sun, 3 Dec 2023 16:57:37 -0800 (PST)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (104-182-38-69.lightspeed.sntcca.sbcglobal.net [104.182.38.69]) (authenticated bits=0) by c.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 3B40vUGM018404 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 3 Dec 2023 16:57:30 -0800
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id 7DD6828C1C3; Sun, 3 Dec 2023 16:57:30 -0800 (PST)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8
To: "Salz, Rich" <rsalz@akamai.com>
cc: Hal Murray <halmurray@sonic.net>, "ntp@ietf.org" <ntp@ietf.org>
From: Hal Murray <halmurray@sonic.net>
In-Reply-To: Message from "Salz, Rich" <rsalz@akamai.com> of "Sun, 03 Dec 2023 23:40:24 +0000." <6D0112DD-602D-4968-B85C-B1024C46B9A9@akamai.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 03 Dec 2023 16:57:30 -0800
Message-Id: <20231204005730.7DD6828C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVYUmsjyC2uXpQgUoHGULN5P3o2UQ0SzkF9jIyn5tD195lFhsKYOdQgsVce0isQtCV78BnFZc97toxmAPxl1dLSMBjM/oCgT1Ss=
X-Sonic-ID: C;tOH2GUCS7hGmhS5nR+6Zsg== M;qNUOGkCS7hGmhS5nR+6Zsg==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/l4x35ZVXJ9Apn8PGpDiAZKMNnJg>
Subject: Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt
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: Mon, 04 Dec 2023 00:57:42 -0000

rsalz@akamai.com said:
> Is it an extension or is the digest?  Looking at figure 8, for example, where
> does it appear?  The text says it's a normal "section 8" (heh) packet, but
> are all the fields present?

It's not an extension.

> I'm trying to figure out how to explain it since what you're proposing is
> different from how I read the RFC. 

It's a non-extension.  I don't think you want to explain it.

You should probably add a paragraph pointing out that RFC 5905 describes a packet format that has a key ID word with a 32 bit field where the type field and length for extensions would go -- with a reference to RFC 7882.

Can that paragraph be added to the IANA registry?

This paragraph from your draft should also be added to the IANA registry:

  *The "Reserved for historic reasons" is for differences between
  the original documentation and implementation of Autokey and
  marks the erroneous values as reserved, in case there is an
  implementation that used the registered values instead of what
  the original implementation used.

Would it be appropriate to add an * to those slots?


-- 
These are my opinions.  I hate spam.