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

[Alexey Melnikov <[e-mail]>]

Hi John,
(Replying with my participant hat on.)

On Sat, Nov 12, 2022, at 9:51 PM, John C Klensin wrote:
> 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.

It sort of does, but the language doesn't match categories from RFC 8126. So at minimum the terminology should be updated to match it.

>  *** 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. 

I don't have strong views on this, as I doubt there would be many new registrations in this particular registry.
However to make registration procedure simpler (because it would match an existing RFC 8126 category), I believe switching to "IETF Review" is the best. If there are existing values already in use, but which are not standardized, I think trying to publish them as "Experimental" is misleading, as there would be no experiment to run. For this reason I think whenever Experimental is allowed, Informational should be allowed as well.

> 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.

I doubt "IESG Review" would be acceptable to IESG, in the past IESG didn't have enough experts, so pretty much always preferred "Specification Required" or "Expert Review".  I would be Ok with either for this registry, but I think it is an overkill.

> 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.

Best Regards,
Alexey