Re: [core] John Scudder's Discuss on draft-ietf-core-oscore-edhoc-10: (with DISCUSS)

Carsten Bormann <cabo@tzi.org> Wed, 03 April 2024 14:50 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 5636EC14F5F4; Wed, 3 Apr 2024 07:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level:
X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 RI8yuwQAIQ4G; Wed, 3 Apr 2024 07:50:26 -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 04437C14F5FA; Wed, 3 Apr 2024 07:50:23 -0700 (PDT)
Received: from smtpclient.apple (p5089a101.dip0.t-ipconnect.de [80.137.161.1]) (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 4V8njS50bxzDCm0; Wed, 3 Apr 2024 16:50:20 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <171209295110.36690.2503046078430078938@ietfa.amsl.com>
Date: Wed, 03 Apr 2024 16:50:09 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-core-oscore-edhoc@ietf.org, core-chairs@ietf.org, core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB6803D5-7D3B-4F63-A757-B0DE825CD5AD@tzi.org>
References: <171209295110.36690.2503046078430078938@ietfa.amsl.com>
To: John Scudder <jgs@juniper.net>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/A1qHx7ipfgK3Gbhd_j3BVHQjD4s>
Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-oscore-edhoc-10: (with DISCUSS)
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: Wed, 03 Apr 2024 14:50:32 -0000

Hi John,

> On 2. Apr 2024, at 23:22, John Scudder via Datatracker <noreply@ietf.org> wrote:
> 
> Regarding the IANA section, I see that the "OSCORE Security Context Parameters"
> registry has a range whose policy is given as "Standards Action With Expert
> Review" so one might argue this ship has sailed... but the more I dig into that
> registry and RFC 9203, the less I understand, so I think it's worth clarifying
> this now instead of propagating confusion. (To continue the "ship has sailed"
> metaphor, I am concerned the ship is lost at sea and we just haven't realized
> it yet.)

Thank you for looking more closely — registration policies are often not receiving the attention they need.
You may want to consult the thread at 

<https://mailarchive.ietf.org/arch/msg/ace/YZrR_wnixKPxmvrbRluKeVnmmbM>

…for a previous discussion of the “Standards Action With Expert Review” label (in the ACE WG).

This form of policy label is standard fare in the CoRE working group.
ISTR that in ancient history there was a case when IESG approved a document with a registration where the actually registered value was arithmetically unsound (there was a reason we wanted experts to look at registration requests), and, ever since, we have been using this combination label liberally.

Should RFC 8126 have picked that up?  Probably.
But then “with” has some quite obvious semantics to it.
(E.g., in fries with ketchup, the fries actually need to be fried.)

Grüße, Carsten