Ok, I have revised the working draft to include additional
issues suggested by on and off-list notes. Several of those
identified issues already called out in -02 either by the errata
or by the inline CREF notes. As a result of the latter, I'd
added an additional subsection to the new appendix that is
essentially an index to the inline CREF notes that I consider
substantive (it doesn't list all of them and YMMD about what is
or is not substantive). While I hope it will be useful, it
turned out to be a lot of work, leading to:
_Grumpy editor's note_
(those who find it amusing can parse that either way -
the ambiguity is intentional)
As most of you have probably deduced by now, I'm very busy and
have little time for IETF work. I'm willing to do this editing
job because I think it is important and overdue, but it isn't
going to happen unless it is a group effort. This means that,
while I'm willing to add items to a list of topics to be
discussed, nothing that I believe has any substantive impact is
going into the body text of the document unless there is either
consensus that is rather clear to me (and I never count silence
as support for a position) or some WG Chair or AD tells me that
they see consensus and I should make the change. That, in turn,
implies that I'm going to get increasingly impatient with
suggestions for additions or changes the document has already
listed or covered, strongly implying that those making those
suggestions have not read the draft (or at least the current
version). My expectation is that people will actually read
before commenting. I also expect that, if I prepare a message
explaining changes that people will read that. For those people
who don't like my long messages, I'm happy to have a volunteer
to prepare a summary short enough to avoid TL;DR comments, but
that still won't save people reading the drafts themselves. I
promise in return that I won't make non-trivial changes without
documenting them so that a diff from a prior, carefully-read,
version plus my notes should be sufficient to keep track of what
is happening without reading all 100+ pages every time.
Another warning about my likely reactions both personally and as
editor. It is generally believed that a small number of
providers (certainly under a dozen) are carrying or handling a
very large fraction of Internet mail traffic as measured by
either message count or total byte count. I have no reason to
doubt that belief although, especially given all of the
spam-originating systems and bots and the mail service providers
in places like China and India who rarely show up on those lists
but carry a lot of traffic, I'm occasionally suspicious about
the numbers quoted. However, there are also many thousands of
systems out there that are able to act as SMTP senders and/or
receivers, even after excluding spam generators and academic and
enterprise servers that have been outsourced to those big
providers. When one adds in IoT and IIoT systems that generate
or process email, that is probably tens or hundreds of systems,
at least before we start quibbling about what is an SMTP system
and what is a Submission one. When someone says "NN% of mail
does X or uses Y", with NN large, we should pay attention to
that but it should not be sufficient for making changes in what
the standard requires. It might, instead, be a good reason to
better explain why the standard says what it does even if those
providers choose to not conform. And whether that explanation
should make it into 5321bis or some supplemental A/S or BCP is
another, separate, question. If, instead, we conclude that
whatever that handful (or two) of providers do is really the
standard, then there is little point in revising 5321 and,
perhaps instead, we should take the IETF out of the business of
specifying some or all email standards and encourage those
providers to form a consortium to publish a specification of
what they are doing so that everyone else can get in line.
Grump!
john
In addition, I hope everyone is aware that experience predicts
that every topic-level issue that is added to the "perhaps
should be covered in 5321bis" list lowers the odds that we will
actually converge before enough people run out of energy to have
the remainder represent additional consensus.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp