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 Kühlewind <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] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
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
- [Ace] Mirja Kühlewind's No Objection on draft-iet… Mirja Kühlewind via Datatracker
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Barry Leiba
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Benjamin Kaduk
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Mirja Kuehlewind
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Mike Jones
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Barry Leiba
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Jim Schaad
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Mike Jones
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Benjamin Kaduk
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Mike Jones
- Re: [Ace] Mirja Kühlewind's No Objection on draft… Mike Jones