[Gendispatch] Re: [dispatch] Re: IANA policies "... with expert review" (Re: [Alldispatch] IETF-Wide Dispatch – Call for topics)

John C Klensin <john-ietf@jck.com> Mon, 27 May 2024 00:28 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: alldispatch@ietfa.amsl.com
Delivered-To: alldispatch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D0F71C14F6A6; Sun, 26 May 2024 17:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EcffvtBhmnXi; Sun, 26 May 2024 17:28:45 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBFBC14F61D; Sun, 26 May 2024 17:28:44 -0700 (PDT)
Received: from [] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1sBOED-000LXW-NJ; Sun, 26 May 2024 20:28:41 -0400
From: John C Klensin <john-ietf@jck.com>
To: Donald Eastlake <d3e3e3@gmail.com>, gendispatch@ietf.org
Message-ID: <948B28ECBEDAA82302196237@PSB>
In-Reply-To: <CAF4+nEEaObL_KtwfoaMu9EJm1NUtC0x=9t2yY1FFsQ3=KwdrQA@mail.gmail.com>
References: <CADNypP-t3r_978s3ZgrpBmwV1g9mMrWuHqqibAKSgvEA==j8Pg@mail. gmail.com> <886F613C-D942-4D07-879C-817BFC74455A@tzi.org> <CAF4+nEEaObL_KtwfoaMu9EJm1NUtC0x=9t2yY1FFsQ3=KwdrQA@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Hits: max-recipients
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Approved-At: Tue, 28 May 2024 18:33:57 -0700
CC: Alldispatch@ietf.org, secdispatch <secdispatch@ietf.org>, dispatch@ietf.org, rtgwg@ietf.org, opsawg@ietf.org, int-area@ietf.org, ops-area@ietf.org, witarea@ietf.org, core-chairs@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Gendispatch] Re: [dispatch] Re: IANA policies "... with expert review" (Re: [Alldispatch] IETF-Wide Dispatch – Call for topics)
List-Id: General Area Dispatch <gendispatch.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/lbwPVlM2VZfETx_1fZSuUeFuUCw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Owner: <mailto:gendispatch-owner@ietf.org>
List-Post: <mailto:gendispatch@ietf.org>
List-Subscribe: <mailto:gendispatch-join@ietf.org>
List-Unsubscribe: <mailto:gendispatch-leave@ietf.org>
Date: Mon, 27 May 2024 00:28:49 -0000
X-Original-Date: Sun, 26 May 2024 20:28:35 -0400

--On Sunday, May 26, 2024 17:39 -0400 Donald Eastlake
<d3e3e3@gmail.com> wrote:

> It may be of interest that in some cases blocks of parameter values
> in RFC 9542 and its predecessors back though RFC 5342 are assigned
> under a policy called, in these RFCs, "IESG Ratification". This
> provides for Expert Review and then, if the Expert approves or is
> uncertain, the final decision is made by the IESG. See Section
> 5.1.2 of
> https://datatracker.ietf.org/doc/rfc9542/
> (https://www.rfc-editor.org/rfc/rfc9542.html#name-expert-review-and
> -iesg-ratif).


Yes, and this is part of a problem I'm not sure whether ALLDISPATCH
wants to dig into (I've had fantasies about a separate BOF).
Carsten's draft, my draft, and your example above may all be
indicative of a broader problem.  Another part of  the problem, sort
of mentioned and partially addressed in my draft, is that there
appear to be a growing number of topics in which there is tension
between the value of trying to be sure everything relevant gets
registers and getting high-quality review and engagement.  For those
reasons and, I gather, others  with less sweeping possible
implications, it seems clear that RFC 8126 is in serious need of
reexamination and revision.

Unfortunately, at least as I understand it, a draft revision for
community discussions was promised over two years ago and has been
promised and/or requested by various ADs several times since.  The
draft has not appeared and, if progress is being made, I, at least,
have seen no sign of it: certainly there has been no I-D.

So, can we either move toward a DISPATCH session to discuss and
record issues that should be addressed in 8126bis and, to the degree
possible, a plan for getting a draft of such a document, or a session
of some sort devoted to the "IANA Considerations" question and
issues.  If the latter has to be a side meeting, would it be possible
to schedule the ALLDISPATCH session in a way that allows organizing
it and finding a good time?


p.s. to save some reading, at least until it is necessary, your
comment and my draft are about the same idea: taking two well-known
registration policies and combining them in a way that meets a
particular set of needs.  In the case you cite, it would be IESG
Approval if Expert Review does not work out well.  In the case I went
after, it was dealing with the tension I mentioned above by allowing
the would-be registrant to choose between "just get it registered"
(essentially FCFS) and much more serious community review with the
registry telling those looking at it whether the latter occurred.