IETF Logo Mail Archive

Re: [Ntp] New Version Notification for draft-rsalz-update-registries-00.txt

Danny Mayer <mayer@pdmconsulting.net> Mon, 18 January 2021 03:35 UTC

Return-Path: <mayer@pdmconsulting.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 409A03A0CCA for <ntp@ietfa.amsl.com>; Sun, 17 Jan 2021 19:35:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level:
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 l68ypcb2zz0v for <ntp@ietfa.amsl.com>; Sun, 17 Jan 2021 19:35:46 -0800 (PST)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C873A0CC7 for <ntp@ietf.org>; Sun, 17 Jan 2021 19:35:31 -0800 (PST)
Received: from L34097OUS.fios-router.home (pool-108-26-201-164.bstnma.fios.verizon.net [108.26.201.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4DJy9G272gzMNDp; Mon, 18 Jan 2021 03:35:30 +0000 (UTC)
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Daniel Franke <dfoxfranke@gmail.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>, "ntp@ietf.org" <ntp@ietf.org>
References: <160866842930.12375.2768184613474168188@ietfa.amsl.com> <8E362353-B91C-445B-B16E-166BE3A9045A@akamai.com> <20210104144735.GA2992437@localhost> <3FBAA9E7-A251-4C68-9231-A0271227EF6C@akamai.com> <43EFABEB-5829-443B-A29B-C3B4D1228BFD@akamai.com> <CAJm83bB3DmjF0y0G-FC-s_bHCW3-tw5SDpko8Eoftt9QsH8xcQ@mail.gmail.com> <A0E76A23-7064-4800-A821-62BA22F12257@akamai.com>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <4b46f71b-34b7-9342-f3ec-48f094dd75c6@pdmconsulting.net>
Date: Sun, 17 Jan 2021 22:35:29 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <A0E76A23-7064-4800-A821-62BA22F12257@akamai.com>
Content-Type: multipart/alternative; boundary="------------EF0814E782A5FF82CED22F46"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/vdXzv0Ndz0RZ5Z-u5Aa_1vmzhNU>
Subject: Re: [Ntp] New Version Notification for draft-rsalz-update-registries-00.txt
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, 18 Jan 2021 03:35:49 -0000

On 1/6/21 2:51 PM, Salz, Rich wrote:
>
> On Wed, Jan 6, 2021 at 10:42 AM Salz, Rich 
> <rsalz=40akamai.com@dmarc.ietf.org 
> <mailto:40akamai.com@dmarc.ietf.org>> wrote:
>
>     And also where are the response and error flags defined?  A quick
>     search in RFC 5905 didn't find anything obvious.
>
>   * They're only defined within the context of Autokey. RFC 5906
>     describes them, but fails to reserve the registry space that it
>     would need to use them correctly.
>
> Thanks for the pointer.  Reading Section 10 of RFC 5906 closely, it 
> looks like the partitioning of the field type into R/E/Code/Field 
> parts is limited purely to autokey, and not intended to apply to 
> extensions overall.
>
That was the intent  of the registry entries and it may have been 
incorrectly set up. It was a bad idea to put these bits into the 
extension id field in the first place so this was the best way to 
reserve the fields so that the rest of the ID's were available without 
totally destroying the way extension fields were meant to be.

It took a while to get this set up but at least it allowed autokey 
(RFC5906) to move forward.

Danny

v2.23.0 | Report a Bug | By Email