[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.