[core] John Scudder's Discuss on draft-ietf-core-oscore-edhoc-10: (with DISCUSS)
John Scudder via Datatracker <noreply@ietf.org> Tue, 02 April 2024 21:22 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC72C14CE29; Tue, 2 Apr 2024 14:22:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-oscore-edhoc@ietf.org, core-chairs@ietf.org, core@ietf.org, cabo@tzi.org, cabo@tzi.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <171209295110.36690.2503046078430078938@ietfa.amsl.com>
Date: Tue, 02 Apr 2024 14:22:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/CaK5R4gq1wc3CN5-dTN3uRXoU2U>
Subject: [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
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: Tue, 02 Apr 2024 21:22:31 -0000
John Scudder has entered the following ballot position for draft-ietf-core-oscore-edhoc-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-edhoc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document, which in general I found clear. I have one concern, which I hope will not be too annoying. 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.) "Standards Action With Expert Review" isn't one of the defined RFC 8126 policies, which is OK of course, but if not using one of the defined policies, I think it's important to be explicit and clear about exactly what the semantics of your non-standard policy are. Or, in the words of RFC 8216 §4, Newly minted policies, including ones that combine the elements of procedures associated with these terms in novel ways, may be used if none of these policies are suitable; it will help the review process if an explanation is included as to why that is the case. In your §8.4 you have, Specifications are required for the "Standards Action With Expert Review" range of point assignment. You didn't have to invent a nonstandard policy for that -- Standards Action already has a strong requirement for specification. That's the only point in your document I see that's specific to "Standards Action With Expert Review". Am I supposed to assume that this policy inludes all the restrictions and requirements of the RFC 8126 style "Standards Action", adding the designated expert as an additional gatekeeper, in addition to the SA gatekeepers, those being (at least) the WG chairs, WGLC, IETF LC, and IESG review? Does RFC 7120 style Early Allocation apply? A plain reading of RFC 7120 implies it does not: The early allocation mechanisms are applied only to spaces whose allocation policy is "Specification Required" (where an RFC is used as the stable reference), "RFC Required", "IETF Review", or "Standards Action". That is to say, "Standards Action with Expert Review" is on its face, not the same as "Standards Action". On the other hand, if RFC 7120 should somehow apply, what is the role of the designated expert? Note that RFC 7120 doesn't say anything about designated experts, the parties involved are the authors, WG chairs, and AD(s). It seems to me that if you insist on using this variant policy, instead of just "Standards Action" with no sprinkles or whipped cream, then you should explicitly say what aspects of "Standards Action" you expect it to inherit. Or, you could go with just "Designated Expert" with no "Standards Action" chocolate sauce, and include in the instructions to the expert for that range, that "values are assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream" plus maybe something about following an RFC 7120-like procedure for early allocation, if desired.
- [core] John Scudder's Discuss on draft-ietf-core-… John Scudder via Datatracker
- Re: [core] John Scudder's Discuss on draft-ietf-c… Carsten Bormann
- Re: [core] John Scudder's Discuss on draft-ietf-c… Carsten Bormann
- Re: [core] John Scudder's Discuss on draft-ietf-c… John Scudder
- Re: [core] John Scudder's Discuss on draft-ietf-c… Carsten Bormann
- Re: [core] John Scudder's Discuss on draft-ietf-c… Marco Tiloca