Re: [ietf-smtp] draft-freed-smtp-limits

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

--On Friday, August 4, 2023 15:54 -0400 Hector Santos
<[e-mail]> wrote:

> I always supported Ned's (rip) work with advertising ESMTP
> limits.  It is applicable in controlled areas where it can
> help clients with the EHLO posting of session and transaction
> limits.
> 
> What I don 't see in my review of the 05 draft are
> Connection Limits.   Example is sending bulk mail to yahoo.com
> <http://yahoo.com/>.  Out of the box, its connection limit is
> 4.    Exposure of a CONNMAX=4 can better trained smart smtp
> clients to calm down their outbound clients.

Hector (and anyone else with similar suggestions),

First, thanks for the careful reading and not.

I'm deliberately not considered adding additional limit
specifications to Section 4 because I have no way to evaluate
whether Ned would have liked those parameters or how they were
described.  I am struggling to try to keep this document "his",
i.e., one that we can have great confidence he would have
approved and hence leaving his as lead author rather than making
him into a Contributor.

If there is consensus that strategy is not worth it, I'll "fix"
the author list and start considering such suggestions but that
is definitely not my personal preference.  Otherwise, I suggest
that you (and others with other suggestions) start drafting
brief documents describing those parameters and values and the
reasons for them so that, after this one is published, you can
move efficiently forward with registrations.

> LOL, I always wanted to say it — Ship it!! <g>

:-)

   best,
    john


p.s. I've gotten several other comments from Murray.  The ones
either of us consider essentially procedural (such as a
description of Designated Expert considerations and a note about
the registration requirements consistent with the comments below
are already in the working version of -06).  I'm going to hold
posting it until there is time for others to comment unless
someone wants to see  those changes sooner.  But, as I said,
please make comments soon.

> 
> 
> —
> HLS
> 
>> On Aug 4, 2023, at 10:47 AM, John C Klensin
>> <[e-mail]> wrote:
>> 
>> Hi.
>> 
>> As a few of you might have noticed, I, with some help from
>> Murray, got draft-freed-smtp-limits-05 posted yesterday (it
>> should have gone up Friday, but that is another story that you
>> can probably deduce at least part of from the note at the top
>> if you are interested).  It contains changes/ corrections
>> that, with two major exceptions, reflect all of the
>> comments/suggestions I could find on the mailing list since
>> the prior version was posted in early November.  Those
>> exceptions were:
>> 
>> * Suggestions for significant changes in the protocol such as
>> adding additional limit keywords.  I decided to put them aside
>> on the grounds that I have no way to know how Ned would have
>> felt about them and that, in turn, would violate the boundary
>> I'm trying to keep about keeping his name on the document iff
>> any changes are clearly aligned with what he would have
>> wanted. Especially given the low-pain registration plan for
>> new keywords (see below), deferring those suggestions seems
>> reasonable but I'm happy to hear arguments to the contrary.
>> 
>> * The whole business about caching (Section 3.8). Dave pointed
>> out an issue or two in November and Murray pointed out a
>> different set in an AD review of the draft.  I fixed the issue
>> Dave raised that was obvious, but then there are the others.
>> While I've been trying to ignore the issues, that clearly will
>> not work.  Those issues include conditions under which the
>> cached data should be reset, what a new EHLO command in the
>> same session, or a different session, in which the extension
>> is not mentioned means (including where a server response
>> should include limit values or whether that is optional, etc.
>> Options that I can see now include just dropping the
>> subsection or trying to identify and cope with all of the
>> cases the current text leaves uncertain.  The latter would
>> take us into "what would Ned have wanted" territory as well
>> and some non-trivial technical issues.  Thoughts?
>> 
>> There is also an odd complication with the IANA considerations
>> and registration of new limits (See Section 7.2).  The text
>> says "Specification Required" but the current registry and
>> subregistry for Service Extensions and their parameters
>> specify Standards Action or IESG-approved Experimental.  We
>> went through the problems that causes, and why Specification
>> Required isn't a good answer either, in EMAILCORE and I think
>> the two-model system specified there is probably right for
>> this case, especially since approval of 5321bis will change
>> the requirements for those registries.  So, unless we want
>> LIMITs and its parameters to be unique among extensions,
>> either I need to write some tricky text, or we need to create
>> a normative reference to 5321bis (holding up publication of
>> this), or the either long-promised revision to 8126 or the
>> long-threatened update to it to include just that option (an
>> I-D I started on two weeks ago when I noticed the "need to do
>> something about this" note in 5321bis).   Thoughts?
>> 
>> Finally, I'd appreciate people looking at what I've done with
>> the Acknowledgments (Appendix A), seeing if it feels about
>> right and, if not, making suggestions.
>> 
>> The draft clearly needs another revision before going to IETF
>> LC, but I'd like to get that posted while things are fresh in
>> our minds.  So, comments and suggestions would be very much
>> appreciated, but, please, soon.
>> 
>>   john
>> 
>> 
>> _______________________________________________
>> ietf-smtp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-smtp
>> 
>