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

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

Return-Path: <john-ietf@jck.com>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2D42EC1CAF30; Mon, 27 May 2024 08:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PH6hYJFAsoKC; Mon, 27 May 2024 08:41:34 -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 25782C1CAF2A; Mon, 27 May 2024 08:41:33 -0700 (PDT)
Received: from [] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1sBcTX-000Agi-4d; Mon, 27 May 2024 11:41:27 -0400
Date: Mon, 27 May 2024 11:41:21 -0400
From: John C Klensin <john-ietf@jck.com>
To: Carsten Bormann <cabo@tzi.org>
Message-ID: <574B209A359232A4FCA2741F@PSB>
In-Reply-To: <458EF10A-34CD-4C0D-AC83-E236872777C6@tzi.org>
References: <CADNypP-t3r_978s3ZgrpBmwV1g9mMrWuHqqibAKSgvEA==j8Pg@mail. gmail.com> <886F613C-D942-4D07-879C-817BFC74455A@tzi.org> <CAF4+nEEaObL_KtwfoaMu9EJm1NUtC0x=9t2yY1FFsQ3=KwdrQA@mail.gmail.com> <948B28ECBEDAA82302196237@PSB> <458EF10A-34CD-4C0D-AC83-E236872777C6@tzi.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Donald Eastlake <d3e3e3@gmail.com>, gendispatch@ietf.org, Alldispatch@ietf.org, Eliot Lear <lear@lear.ch>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Gendispatch] Re: [Alldispatch] [dispatch] Re: IANA policies "... with expert review" (Re: IETF-Wide Dispatch – Call for topics)
List-Id: General Area Dispatch <gendispatch.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/vwdlDt8Nf2FVr0j8NMHiVv9F2OQ>
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>

(Responding to this but trimming as Eliot suggested and incorporating
one of his comments)

--On Monday, May 27, 2024 08:42 +0200 Carsten Bormann <cabo@tzi.org>

> Hi John,
>> […] 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.  
> I think that a two-tiered system (permanent/provisional, the one
> your draft proposes, the recommended flag) generally is the best
> answer to this problem.  Not sure there is a one-size-fits-all here
> that could go into the BCP.

First, I agree with Eliot about provisional expiration that don't
expire... and I'd add that the expirations have to be meaningful.  In
a world in which, at least for most protocols, nothing prevents
someone from inventing a keyword, value, or parameter and just using
it with no registration at all, I don't see how one really gets rid
of a provisional registration.  A different situation might occur if
"provisional" were defined, not in terms of entering a value into the
registry but as applying to the definitional material.  Then one
could say "the definition of this value is tentative pending
community review" and figure out what to do if that review never
happened (maybe within a fixed timeout) or was negative, as long as
that action did not including removing the value itself.

>> 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.
> My draft specifically did not want to wait for such a grand
> "second systems syndrome" draft to be developed. I'd rather
> do incremental steps.

To a considerable extent, me too.  But, so far, the response from the
direction of the IESG to my draft (and some weeks or months of
intermittent discussions preceding it) has been "8126 is being
revised".  If we can say "let's recognize that 8126bis is not moving
and hold it until some of these incremental changes are considered
and processed" or even "8126bis is not a barrier to incremental work
although we may want to fold some of that work into it as it
develops", then, yes, one at a time at least until overlaps dictate a
more integrated approach.

> Once we have taken a few of them, we might do an editorial round
> and merge them into a bis. Litigating all open issues at once plus
> trying to achieve editorial perfection is not what I'd want us to
> aim at.

More or less agreed.  See above.

>> 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.
> Right.  Let's not get mired in such an effort.
>> 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.  
> Note there the are different ways to "combine".  My draft is a
> conjunction (logical AND).  Other approaches are a disjunction
> (logical OR), potentially with a semantically meaningful indication
> in the registration which path was taken.

The example Don mentioned may be yet another case, possibly along
with my comments about "provisional": a sort of serialization with
different conditions on the need for, or use of, the second step.

The distinct you make is, indeed, important.    And that is something
else that could be done incrementally.  Section 4.12 of RFC 8126
already talks about combinations of policies although it seems to me
to be focused on different origins for registration requests.  We
could think about an update to it only, incorporating your AND/OR
distinction and maybe a serial one that might draw on my comments
above about a type of provisional registration.  That would be more
sweeping than the very specific combinations in our two current
drafts, but far narrower than trying to go through 8126 looking for
and fixing glitches, errors, bad organizational choices, ideas that
are obsolete in practice, changes in IANA and PTI, etc.   My guess is
that, by drawing material from this discussion, our two drafts, and
Don's example, such an update draft would not be hard to do.   With
such a more general "combinations" document in hand, we could then
decide whether we needed one or more "specific combination cases"
documents.  Or maybe we should do it the other way around, processing
those two "combination" documents since they are already on the table
-- as you point out, one conjunction and one disjunction -- possibly
with a to-be-developed serialization document, and then, as a
follow-on next step, figure out how to update/ replace that section
of 8126 and tune anything that doesn't work with it.

Similar approaches could be taken vis-a-vis Section 4.13 of RFC 8126
on Provisional Registrations.