--On Friday, September 15, 2023 12:49 -0400 Paul Kyzivat
<[email protected]> wrote:
> Document: draft-freed-smtp-limits-06
> Reviewer: Paul Kyzivat
> Review Date: 2023-09-15
> IETF LC End Date: 2023-10-04
> IESG Telechat date: ?
>
> Summary: This draft is on the right track but has open issues,
> described in the review.
>
> Minor Issue: How the new IANA registry is specified
>
> Section 7.2 seems to conflate two things:
>
> - the information that must be provided in a specification
> document that registers new limits
>
> - the information that is to included in the registry itself
>
> ISTM that the registry itself should contain the limit name
> and a reference to the specification document. It might also
> contain the value syntax, or at least an indication if a value
> is allowed.
>
> The descriptions of semantics, restrictions, and security
> considerations don't lend themselves to inclusion in the
> registry, but should be clearly spelled out in the
> specification.
>
> Also, the request for the new registry should probably include
> its exact name ("SMTP Server Limits"?), and that it should be
> included within the "MAIL Parameters" protocol registry.
>
> Otherwise IMO this document is in fine shape to move forward.
Paul,
Thanks for the careful reading. While I'd be happy to make the
adjustments you suggest if the community, the IESG, or IANA
prefers them, some of the vagueness, especially about registry
organization and names, was deliberate. FWUW, let me explain,
easy part first (and setting aside my preference for making as
few changes as possible to Ned's original text):
(1) As you have certainly been around long enough to remember,
traditionally the requests in IETF specifications to IANA about
setting up registries were as minimal as possible, relying on
them to sort registry specifics out in a way that makes sense.
This specification was written with that model in mind even
though things have evolved toward more specificity in recent
years. While much of the reason for that model was just
tradition, there was also a specific and pragmatic reason in
this case: I am expecting (or at least hoping for) changes to
the structure and definitions of the Mail Parameters registry in
the relatively near future. If and when they occur, this
document (and several others) may need updates to match the new
arrangements. To the extent to which we can avoid going into
detail in a specification like this one, that update could be
short and general. If we have to un-do unnecessary details, it
will take up community and IESG time that can almost certainly
be spent in better ways.
And that brings me to the "why" of the above.
(2) In the last several years, there has been a gradual shift in
IETF thinking about registrations of values for namespaces whose
total size is not inherently restricted from what I would
describe as a focus on quality, typically including community
review, to try to get things right, to a focus on just getting
things registered to prevent accidental conflicts and consequent
confusion and interoperability problems. The introduction to
Section 4 of RFC 8126 explains some of the tension between those
two perspectives and the comment at the beginning of Section 7.2
of the I-D at least hints at the problem (and the change I
predicted above).
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.
john
p.s. did you intend to copy the Last Call list?
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
