Re: [ietf-smtp] Registration policies for draft-freed-smtp-limits and elsewhere

[John C Klensin <[e-mail]>]

--On Monday, August 7, 2023 15:35 -0400 John Levine
<[e-mail]> wrote:

> It appears that John C Klensin  <[e-mail]> said:
>> As implicitly threatened above, I have just posted
>> draft-klensin-iana-consid-hybrid-01, "Hybrid IANA Registration
>> Policy".  ....
> 
> I looked at it and honestly, if we want to chage RFC 8126, we
> should simplify the registration rules, not add yet more
> complication.
> 
> There are basically two kinds of regstry, small ones where we
> might run out of code points, and big ones where we won't.
> (Small could be under 256 available, big is over 50,000.  I
> can't think of any in between.)
> 
> For small ones, we apply traditional quality control, expert
> review up to standards action. For the large ones, it's FCFS.
> We can certainly encourage registrants in large ones to
> provide detailed specifications and offer help to do so, but
> even if they don't, register it anyway. 

I agree with the small-vs-large distinction.  I'm, separately,
getting increasingly skeptical of how well some of our
"expert"-based models are working in terms of encouraging  good
specifications and getting community input as well as the number
of those slots that, according to the IANA protocol registry
page,  seem to be unfilled and how well we are training people
to replace incumbents in other slots, especially for older
protocols.  Other discussions suggest that we never want to have
an Expert say "no" because most registrants would respond by
just appropriating the name and doing whatever they wanted to do
anyway.  If a would-be registrant wants review input, and/or
help, we should make it easy to ask and have that help come from
either per-registry teams or per-registration volunteers.

We've run into further complications in the recent past as to
whether the main responsibilities of the Expert are to advise
IANA, to help (shepherd?) the registrant, or to represent and
protect the community.  In most practical situations, there is
no conflict among those roles.  In others,...

Given that and following your reasoning (and my interpretation
of Dave's), it would leave us with a far simplified registry
specification and policy list. Something like:

(1) Small registry/ scarce resources: Probably Standards Action,
to protect the resource, to raise the odds of high-quality
documentation, and to provide a discussion venue for options
other than registration if needed.  One could think about some
sort of "IETF consensus to register" model, but that would
probably amount to that same thing  in practice and would
require specifying a new process.

(2.1) Registrant intends to provide good documentation, wants
advice, community input, or whatever value official IETF
approval brings.  Standards Action.

(2.2) Registrant does not want any of those things, just to get
the string registered.  Or tries for 2.1 and either loses or
gives up.  FCFS.

Probably we suggest (or require) that a registry definition
include a pointer to a mailing list to which a registrant can
direct questions or get started on 2.1.  Absent an active WG, an
active list for a closed WG, or something equivalent, the
default for such a list could be AREANAME-dispatch,
[e-mail], or something else.  Even if hard to find, almost
certainly easier than finding and appointing a DE.

All of the other options disappear.  No more Designated Experts
(aka "Kings for the Protocol Registry") and no obligations on
ADs to keep those positions filled or on some combination of the
IESG and IANA to manage them and make sure they are responding
when needed and adequately.  No hairsplitting about the
boundaries among ten alternatives and probably little or no need
for protocol-specific or registry-specific registration
procedures.

If that were going to be the plan, then I think most of the
needed text for (1) is already in 8126 and most of (2) is in the
I-D.  We'd have to remove a lot of context and comparisons from
both, but the result would be mostly a cut and past job yielding
a much smaller and clearly document.

Is that more or less what you had in mind?

If so, how do others feel?

best,
  john