Re: [Gen-art] Genart Last Call review of draft-freed-smtp-limits-06

[Paul Kyzivat <[e-mail]>]

John,

I appreciate your points. I understand that there are tradeoffs. Perhaps 
we do need community input on this.

Normally I copy the wg on genart reviews. Since there was no wg here I 
didn't do that, and forget to copy the Last Call list. How do I fix that 
and include your reply? Should further community discussion occur on the 
last call list, or is something more bounded better?

More inline below.

On 9/17/23 2:34 PM, John C Klensin wrote:

[snip]

> The EMAILCORE WG got hit by that problem while working on
> draft-ietf-emailcore-rfc5321bis which, among other things,
> specifies most of what appears in that Mail Parameters registry.
> It is particularly important for email because there has been a
> history of implementations and providers making up their own
> stuff and not bothering to register.  Most of the relevant
> registries have traditionally specified standards track or
> IESG-approved Experimental, which is clearly too high a barrier
> to entry for anyone who does not want to take the time or who
> just does not want to mess with, or recognize the authority of,
> the IETF or IANA.  It isn't clear that Specification Required is
> a much lower barrier, especially for that second group or if the
> Designated Expert initiates a community review.  If one wants
> no, or absolutely minimal, barriers, then only FCFS will do.  On
> the other hand, there are implementers and designers who still
> think that the IETF is useful and that a serious community
> review could improve the details of what they want to do.  So
> the plan, and the one preferred for name-value pairs for SMTP
> LIMITS, if that the registrant picks between FCFS (with minimal
> requirements for documentation or anything else) and full
> standards track review, including the documentation requirements
> for the latter. The registry would then indicate which one was
> chosen and potentially contain different information for the two.
> 
> See Section 8 of draft-ietf-emailcore-rfc5321bis-19 or
> draft-klensin-iana-consid-hybrid for different takes about how
> the above might be specified, but with the understanding that
> the right way to approach this would be in a revision to RFC
> 8126/ BCP 26.

My philosophy on registries is that

1) Documents referencing a registry need to be absolutely clear where 
the registry can be found. (I want to be able to use what is in the 
document to search and find the right registry the first time!)

And the registries themselves need to:

2) Provide sufficient info so a developer implementing a spec can 
discover all specs relevant to him by following references, including 
references to registries. (So we don't require the developer to be psychic.)

3) Give enough information to screen out most entries that aren't 
relevant to a developer's task without reading the associated document. 
(This is most important when there are many entries in the registry.)

I'm troubled by FCFS registries that don't provide enough information to 
be understood by an arbitrary developer without prior knowledge. This 
makes the item proprietary. I guess I'm ok with it if the intent is to 
support proprietary features.

>    john
> 
> p.s. did you intend to copy the Last Call list?

Yes :-(