Re: [core] Gunter Van de Velde's No Objection on draft-ietf-core-oscore-edhoc-10: (with COMMENT)

Carsten Bormann <cabo@tzi.org> Fri, 29 March 2024 10:56 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4B0C14F6A4; Fri, 29 Mar 2024 03:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 3q2bGz20lPAC; Fri, 29 Mar 2024 03:56:16 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDB5C14F6AC; Fri, 29 Mar 2024 03:56:08 -0700 (PDT)
Received: from eduroam-0440.wlan.uni-bremen.de (eduroam-0440.wlan.uni-bremen.de [134.102.17.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4V5clT245QzDCcl; Fri, 29 Mar 2024 11:56:05 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <171170205856.50363.11408304135192668336@ietfa.amsl.com>
Date: Fri, 29 Mar 2024 11:56:04 +0100
Cc: The IESG <iesg@ietf.org>, draft-ietf-core-oscore-edhoc@ietf.org, core-chairs@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 733402564.754813-8992459faf10b36de707dd5953bf8c5d
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADD7D503-4854-4A73-9F95-6E3D254C6A7E@tzi.org>
References: <171170205856.50363.11408304135192668336@ietfa.amsl.com>
To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/eigpv9qdZEAbTBRMXBchchYU8UI>
Subject: Re: [core] Gunter Van de Velde's No Objection on draft-ietf-core-oscore-edhoc-10: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2024 10:56:20 -0000

Hi Gunter,

thank you for noticing this.

> On 2024-03-29, at 09:47, Gunter Van de Velde via Datatracker <noreply@ietf.org> wrote:
> 
> idnits spits up a downref (ref. 'I-D.ietf-core-target-attr').

This is an approved document, RFC-to-be 9423, which has completed AUTH48 and is currently in TI state (tools issue).
As far as I know the xml2rfc bug (https://github.com/ietf-tools/xml2rfc/issues/685) has been fixed and we are just waiting for the next xml2rfc release, which of course went slow around IETF119.

I expect RFC-to-be 9423 to be published before the RPC starts editing, but certainly before it reaches AUTH48 state.  If not, the two documents will go into a cluster...

> Not sure if in the reference section an IANA registry reference is better
> informational then normative reference.

That is indeed a good question, which comes up again and again.
I don’t think we have heard a definitive answer.
My view:
Oscore-edhoc needs those registrations, so the IANA registry itself (which ultimately assigns the names for those) definitely is a normative reference; we can skimp on making the document that establishes the registry (9423) normative (although it indirectly is).  Not making the registry document normative can help if it is approved (i.e., the registry exists) but not yet published.

Grüße, Carsten