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

Barry Leiba <barryleiba@computer.org> Mon, 28 October 2019 21:00 UTC

Return-Path: <barryleiba@gmail.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 B8199120091; Mon, 28 Oct 2019 14:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 eLpT1xCnTgUq; Mon, 28 Oct 2019 14:00:39 -0700 (PDT)
Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29AF120072; Mon, 28 Oct 2019 14:00:38 -0700 (PDT)
Received: by mail-il1-f175.google.com with SMTP id p8so9454506ilp.2; Mon, 28 Oct 2019 14:00:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ypRGvt7veI2HYho733aR0GlHkWJYzL3yB6pE2rVs21A=; b=L+/QaE5GJuJkVNzWIBMDmOXU8f4ClgDRaIQxmy3YbXJjFAr8iWVkGId8O3rWwDT1l3 8RE2DY2gHog0aZy0QQ3pZa7V0THdEqNB44EsbJM+OYJlvKZH8CVo92I0vqaarnLQLB/i hl7UMHhtiEahZ33nbxrif6BjZwdzz5RezIX8u6ilpoLdgOSY75/p+tEW49b3yfelQPv2 gcH5L5coIsuNo9raW5xSG59zZgvFwxIrkd0GbhiTpRHTD5XzLwGV1SHavYAgIN2dB4tJ zGPvanjXcgo1AthBjBdd/EQW+BE8U+prWs7BMdj5CTDVVzG3E20Wsmj8m5jdYB0yYga5 nN/w==
X-Gm-Message-State: APjAAAV/WSebnyaPQg6Dbzpp+8HkpC8KGt9ylxVPN1hOSvxraNZZIJub 5cCt4SHIuIXAI0nn7lr27qfSnA8SROdyT6D6b8s=
X-Google-Smtp-Source: APXvYqzz0i/kRBXwZEOeWiZ7ZgZjsjv4QcMhg85D4C5F/xgrPFlqD0gVP576BPINhaYDzNFUr7QB3UMQr3e4VjOaJF0=
X-Received: by 2002:a92:350a:: with SMTP id c10mr5104034ila.140.1572296437799; Mon, 28 Oct 2019 14:00:37 -0700 (PDT)
MIME-Version: 1.0
References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <CALaySJKSmewUn3u2T7Nr5MaCOJ5C=pAii3UB230r+jox5m-4gQ@mail.gmail.com> <20191028153150.GY69013@kduck.mit.edu> <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> <BYAPR00MB0567997BBAC77665CBE19822F5660@BYAPR00MB0567.namprd00.prod.outlook.com>
In-Reply-To: <BYAPR00MB0567997BBAC77665CBE19822F5660@BYAPR00MB0567.namprd00.prod.outlook.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 28 Oct 2019 17:00:26 -0400
Message-ID: <CALaySJLFLCgF5HzgcBQJdRE7WV1fpiYHn1TJYkKqFTo0yVAtDA@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>, Benjamin Kaduk <kaduk@mit.edu>, "Roman D. Danyliw" <rdd@cert.org>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, The IESG <iesg@ietf.org>, "ace@ietf.org" <ace@ietf.org>, "draft-ietf-ace-cwt-proof-of-possession@ietf.org" <draft-ietf-ace-cwt-proof-of-possession@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/E_jOgdUNyYZHFvi2FmWTFxuOctY>
Subject: Re: [Ace] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-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 21:00:41 -0000

The issue isn't using a mailing list.  The issue is the instructions
to IANA about how to do management and tracking, stuff that they do
just fine without working groups trying -- will all good intentions --
to tell them how.

The fact that there are a lot of RFCs that do it just says that
working groups do this frequently, and most ADs don't notice or don't
care.  And the reality is that IANA will manage the registration
process how they do it, accommodating reasonable special instructions
when they can.  The point is that documents shouldn't be giving
special instructions unless there really is something special needed
for a particular reason.

Barry

On Mon, Oct 28, 2019 at 12:19 PM Mike Jones <Michael.Jones@microsoft.com>; wrote:
>
> The practice of using a mailing list for registration requests to enable public visibility of them goes back at least to .well-known URI registrations https://tools.ietf.org/html/rfc5785 by Mark Nottingham in April 2010.  OAuth 2.0 followed this practice in RFC 6749, as did the JOSE specs and JWT in RFCs 7515-19.  The rest is history, as they say.
>
>                                 -- Mike
>
> -----Original Message-----
> From: Mirja Kuehlewind <ietf@kuehlewind.net>;
> Sent: Monday, October 28, 2019 8:54 AM
> To: Benjamin Kaduk <kaduk@mit.edu>;
> Cc: Barry Leiba <barryleiba@computer.org>;; Roman D. Danyliw <rdd@cert.org>;; ace-chairs@ietf.org; 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)
>
> These are all quite recents examples, so maybe the procedures are changing at the moment. I guess we as the IESG should be aware and figure out what the right procedure actually should be here.
>
> > On 28. Oct 2019, at 16:31, Benjamin Kaduk <kaduk@mit.edu>; wrote:
> >
> > 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
> >
> >
>