draft-freed-smtp-limits

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