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

Jim Schaad <ietf@augustcellars.com> Mon, 28 October 2019 22:23 UTC

Return-Path: <ietf@augustcellars.com>
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 603A912094C; Mon, 28 Oct 2019 15:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 a6r03Rqx9LZ7; Mon, 28 Oct 2019 15:23:19 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87318120954; Mon, 28 Oct 2019 15:23:18 -0700 (PDT)
Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 28 Oct 2019 15:23:10 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Benjamin Kaduk' <kaduk@mit.edu>, 'Barry Leiba' <barryleiba@computer.org>
CC: "'Roman D. Danyliw'" <rdd@cert.org>, <ace-chairs@ietf.org>, =?iso-8859-1?Q?'Mirja_K=FChlewind'?= <ietf@kuehlewind.net>, 'The IESG' <iesg@ietf.org>, <ace@ietf.org>, <draft-ietf-ace-cwt-proof-of-possession@ietf.org>
References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <CALaySJKSmewUn3u2T7Nr5MaCOJ5C=pAii3UB230r+jox5m-4gQ@mail.gmail.com> <20191028153150.GY69013@kduck.mit.edu>
In-Reply-To: <20191028153150.GY69013@kduck.mit.edu>
Date: Mon, 28 Oct 2019 15:23:08 -0700
Message-ID: <03c101d58dde$48ca6ee0$da5f4ca0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHSr3aKjjHo5bxNQispkJ+fL0GyYgLO31EFAcgbol2nUaVocA==
Content-Language: en-us
X-Originating-IP: [192.168.0.11]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/UVf0ACeZhrmjM-a6S-0sBGbpRdk>
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 22:23:25 -0000

Given that the author is the same for RFC 7519, RFC 8414 and this document,
I don't know that this says much.   I believe that in part people are trying
to duplicate the behavior of registering media types and perhaps not doing a
good job.

Jim


-----Original Message-----
From: Ace <ace-bounces@ietf.org>; On Behalf Of Benjamin Kaduk
Sent: Monday, October 28, 2019 8:32 AM
To: Barry Leiba <barryleiba@computer.org>;
Cc: Roman D. Danyliw <rdd@cert.org>;; ace-chairs@ietf.org; Mirja Kühlewind
<ietf@kuehlewind.net>;; The IESG <iesg@ietf.org>;; ace@ietf.org;
draft-ietf-ace-cwt-proof-of-possession@ietf.org
Subject: Re: [Ace] Mirja Kühlewind's No Objection on
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

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

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace