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

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

--On Sunday, August 6, 2023 23:35 -0400 John C Klensin
<[e-mail]> wrote:

>...
> --On Sunday, August 6, 2023 18:25 -0700 "Murray S. Kucherawy"
> <[e-mail]> wrote:
> 
>> On Fri, Aug 4, 2023 at 3:10 PM John C Klensin
>> <[e-mail]> wrote:
>> 
>>> What 5321bis sets up is that both are permanent, but the
>>> registry identifies registrations based on the path they
>>> followed (and allows FCFS ones to be reregistered by the
>>> submitter under IETF review-like provisions).  That was a
>>> pragmatic choice (possibly largely mine but the WG has not
>>> objected) based on a desire to avoid figuring out what
>>> "provisional" actually means and, in particular, sounding
>>> like those FCFS registrations were not "real" until they were
>>> pushing into IETF consideration.  Of course, identifying the
>>> model used allows someone looking at the registry to tell the
>>> difference between "someone's bright idea" and "something
>>> actually considered by the IETF".  Presumably the latter
>>> still has value.
>> 
>> I think that sort of model is probably fine too.  My
>> suggestion was just based on other registries (header fields
>> and URI schemes come to mind) where the provisional/permanent
>> model seems to have worked.
>> 
>> If this is a model that we think might be useful for other
>> future registries to follow, then getting it into 8126bis
>> makes perfect sense to me.  The provisional/permanent model is
>> much older but since it's known to work, we could talk about
>> that approach as well.  What I don't know, though, is timing;
>> 8126bis has not, as far as I know, gotten off the ground yet,
>> and I wouldn't want to see 5321bis avoidably delayed. 
> 
> Partially inspired by how far 8126bis has progressed in the
> last year or two and the amount of text on the subject in
> rfc5321bis, I was afflicted by a combination of frustration
> and energy over the weekend.  Watch this (virtual) space.

As implicitly threatened above, I have just posted
draft-klensin-iana-consid-hybrid-01, "Hybrid IANA Registration
Policy".  It is intended to establish the policy model outlined
in this discussion and provide a basis for getting the text out
of rfc5321bis and draft-freed-smtp-limits without getting
everything queued on 8126bis.  If whomever is planning to work
on the latter does so swiftly and has a reasonable expectation
of rapid completion and processing, this I-D may provide useful
material to fold into it.  If the current leisurely pace with
that document continues, this avoids the queuing problem.

Comments on this draft:

(1) It is in need of a careful reading by others.  For those who
are curious, the short-lived -00 version of the I-D was proof
that I'm not good at noticing problems in boilerplate or forms.
In addition to more substantive issues, I have not made a
serious effort to determine which uses of "should", "must", etc.
should (sic) be treated as BCP 14 requirements and would
appreciate any advice.

(2) I need advice on where this should be processed and, in the
medium and long term, discussed.  Do I need to take it to
GENDISPATCH and risk getting bogged down until November or
beyond?  And none of the mailings list shown on
https://datatracker.ietf.org/list/nonwg appear to be a good
match for this document.

(3) I think this model policy is different from the Permanent/
Provisional one although it occurs to me that it might be able
to serve a similar function for some (but not all) registries
and registrations.  I hope that any effort to sort out the
distinctions can be left to 8126bis or longer.

(4) I have thought more about, but not tried to reflect, Dave's
comments about (his words) "conflating registration with quality
control".  I think that position, if carried very far (perhaps
further than he intended), implies that 8126bis should be very
simple, establishing FCFS as the only model.  It should then
probably explain why anything else, including a requirement for
a specification, is a barrier to registration and should be
dealt with as policy or quality control issues rather than
registration ones.  Until and unless the community is willing to
go there, I think this hybrid approach is still helpful. FWIW,
the issue or two registries versus one that Dave raised had been
described in the draft prior to yesterday's conversations.

best,
   john