Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 28 October 2019 15:32 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E788A1208DF; Mon, 28 Oct 2019 08:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 tuwQXpP9dS4U; Mon, 28 Oct 2019 08:32:00 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3141A1208D8; Mon, 28 Oct 2019 08:32:00 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9SFVoGo017379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 11:31:53 -0400
Date: Mon, 28 Oct 2019 08:31:50 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Barry Leiba <barryleiba@computer.org>
Cc: Mirja =?iso-8859-1?Q?K=FChlewind?= <ietf@kuehlewind.net>, draft-ietf-ace-cwt-proof-of-possession@ietf.org, "Roman D. Danyliw" <rdd@cert.org>, ace-chairs@ietf.org, The IESG <iesg@ietf.org>, ace@ietf.org
Message-ID: <20191028153150.GY69013@kduck.mit.edu>
References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <CALaySJKSmewUn3u2T7Nr5MaCOJ5C=pAii3UB230r+jox5m-4gQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALaySJKSmewUn3u2T7Nr5MaCOJ5C=pAii3UB230r+jox5m-4gQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/i35c-oPJRQrFdh9JEtW5eTx4R7Q>
Subject: Re: [Ace] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?=
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 15:32:02 -0000

On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
> Yeh, it's very common for authors to try to tell IANA how to handle
> registrations, and I often push back on that as inappropriate.  There
> are certainly special conditions that IANA should be told about, but
> this is standard work-flow management stuff that ought to be left to
> IANA.  I do think it should be changed before this is published,
> probably just removing that last sentence.

While I'm not opposed to normalizing on a default procedure, I think the
authors were just trying to follow existing examples.

RFC 7519:

   Values are registered on a Specification Required [RFC5226] basis
   after a three-week review period on the jwt-reg-review@ietf.org
   mailing list, on the advice of one or more Designated Experts.
   However, to allow for the allocation of values prior to publication,
   the Designated Experts may approve registration once they are
   satisfied that such a specification will be published.

   Registration requests sent to the mailing list for review should use
   an appropriate subject (e.g., "Request to register claim: example").

   Within the review period, the Designated Experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials should include an explanation and, if
   applicable, suggestions as to how to make the request successful.
   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
   iesg@ietf.org mailing list) for resolution.

RFC 8414:

   Values are registered on a Specification Required [RFC8126] basis
   after a two-week review period on the oauth-ext-review@ietf.org
   mailing list, on the advice of one or more Designated Experts.
   However, to allow for the allocation of values prior to publication,
   the Designated Experts may approve registration once they are
   satisfied that such a specification will be published.

   Registration requests sent to the mailing list for review should use
   an appropriate subject (e.g., "Request to register OAuth
   Authorization Server Metadata: example").

   Within the review period, the Designated Experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials should include an explanation and, if
   applicable, suggestions as to how to make the request successful.
   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
   iesg@ietf.org mailing list) for resolution.

RFC 8447:

   Specification Required [RFC8126] registry requests are registered
   after a three-week review period on the <tls-reg-review@ietf.org>;
   mailing list, on the advice of one or more designated experts.
   However, to allow for the allocation of values prior to publication,
   the designated experts may approve registration once they are
   satisfied that such a specification will be published.

   Registration requests sent to the mailing list for review SHOULD use
   an appropriate subject (e.g., "Request to register value in TLS bar
   registry").

   Within the review period, the designated experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials SHOULD include an explanation and, if
   applicable, suggestions as to how to make the request successful.
   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
   <iesg@ietf.org>; mailing list) for resolution.

[I stopped looking here]

So if we're going to change things around, maybe we should issue an IESG
statement.

-Ben