[Emailcore] Editor's Analysis "Mail Transmission Types" Registry (was: Re: Ticket #76: G.22. IANA Registration Model for Registries Other, Than Service Extensions)

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

Hi.

In the process of fitting notes on this issue into the working
draft that will evolve into rfc5321bis-16, I've done a bit more
study of the text.  Please read through the actual text that
appears in Section 8.1.3 of draft-ietf-emailcore-rfc5321bis-15
[1] as well as G.22 and the slide presented Thursday.  The
following discussion might be a little bit tedious for those who
have been following the documents closely rather than relying on
summaries, slides, and impressions from mailing list comments.
My apologies to them but I believe that, so far, they are a
small minority in the WG.  And, even for them, there is some new
analysis below.

A review of the history and what I think is going on here:

The text of Section 8.1.3 is identical to the third bullet of
Section 8 of RFC 5321.  While RFC 5321 expanded the text (see
below) and added the bullets, the basic text, including the
registration requirement, is unchanged from RFC 2821    You will
recall that Section 8 (the overall IANA Considerations Section)
of rfc5321bis was reorganized (in rfc5321bis-14 and -15) into
subsections and sub-subsections to facilitate moving of
registration specification materials from Section 2.2.2, to
permit other parts of the document and the IANA registries
themselves to more precisely point to relevant material, and to
facilitate conversations like this.  If substantive changes were
made in that process, they were unintentional and should be
flagged and discussed.

Section 8.1.3 (and, again, its predecessors going back to 2001)
specify Standards Action or IESG-approved and RFC-documented
Experimental.  

 *** Conclusion #1: If we follow the "minimal change"
	principle, the default is to leave the text exactly
	as-is.   Changing it to anything else should require a
	demonstrated need and WG consensus.

There is no precise analogy to the registration requirement that
appears in RFC 5321 (and, so far, in 5321bis) in the categories
of RFC 8126 (the current incarnation of BCP 26).  "IETF Review"
comes close, but it allows BCP and Informational RFCs, which
5321 does not.

 *** Conclusion #2: A shift to "IETF Review" requires an
	explicit WG decision to allow Informational and BCP RFCs
	to make the registrations. 

However, an additional sentence was added between 2821 and 5321
that did not appear on the meeting slide.  That sentence (so far
still present in 5321bis) reads:  "This name space is for
identification and not limited in size: the IESG is encouraged
to approve on the basis of clear documentation and a distinct
method rather than preferences about the properties of the
method itself."  That, in conjunction with the IESG's recent
statements about not making decisions without at least
opportunities for community comment, brings us rather close to
the BCP 26 "IESG Approval" category with an added requirement of
RFC documentation or to the "Specification Required" category
with an added requirement of RFC publication and an announcement
and opportunity for community review (somewhat like the
convolutions we were going through for the Service Extensions
registry before we (nominally still tentative) decided to split
it up).  Use of either of those categories would still require
that we make a decision about Informational and BCP documents.

 *** Conclusion #3: If we are going to start making
	changes, it might be nice to align them with BCP 27
	common registration policies.  However, none of them
	quite fit without additional text and/or some explicit
	WG decisions to relax the intent of the requirements.

Finally for 8.1.3, there is the possibility of going to FCFS or
Specification Required.  The latter would require that we
identify an expert or two whom we all trust and, given recent
advice from IANA, a plan about how we are going to supply
experts indefinitely.  I covered my personal opinion about FCFS
for these two registries in a prior note.

   john

p.s.  Neither the slide nor discussion covered the registries
specified in Sections 8.1.2 and 8.1.4.  Watch for a separate
note (and thread) about them.



[1]
https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-15#section-8.1.3
if you like the HTMLized version.