ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

2020-01-02 17:56:05
On 1/2/2020 1:49 PM, John C Klensin wrote:
I'm not suggesting a historical description.  I am suggesting a
rationale for any changes we make, one that is persuasive enough
to overcome the natural resistance to making changes for anyone
(and, where relevant, their management) who thinks they have a

The change will have taken place in the past.

Talking about the reasons that changes /were/ made is by definition talking about history. That the reasons might be more or less compelling doesn't change the fact that the perspective is historical.

In contrast, taking the new document only on its terms -- that is, not in terms of its predecessor -- and talking only about why the current details are wonderful is not historical. But that's not the perspective you suggested, which is why I drew the distinction between inline versus historical. (Having historical discussion in a spec is mostly distracting, especially for someone seeking to implement a current spec, without concern for the history. Such as 10 or 20 years after the spec is published.)


system that is working well for them.  Otherwise, while a few
clarifications (including tracking the errata and issues at a
level similar to most of them) may still be in order, it is not
clear to me a major revision of 5321 is likely to be a good use
of time.

There seems to be some confusion about the difference between changing the protocol versus changing (or removing) portions of text.

For the portions I've suggested removing, the text is, at best, obsolete and at worst plain wrong.

And while you offer the generic concern for unintended consequences, that won't have substance until it gets applied to specifics.


As to whether the IETF usually or normally or even sometimes
does an authoritative rationale document like I'm suggesting,
two examples may help.  Many of the "discussion" materials in
RFC 1122 and 1123 do precisely what I'm suggesting -- explain
why a particular recommendation or requirement is being made in
the hope that people will pay attention rather than expecting
them to do something different (and "different" is important)

To keep things simple: OK. Two docs. One data point. 30 years ago. And for a very, very broad range of issues, rather than a bis specification.


 And, of course, when IPv6 was
adopted, the reasons for the decision, as well as the alternate

Just looked for the RFC that gave the reasons, but couldn't find it. Please cite.

As for publishing alternate proposals doesn't seem relevant to the current point. But that was 25 years ago and not for an incremental bis specification.


proposals, were published.  Only in part because I don't think
it would take much hair-splitting to argue that one or both
examples don't apply,

indeed.


consider how many application-level
protocols we have that are as old as SMTP and whose basic
assumptions or coverage are still being actively reviewed and

Sorry, but I don't understand what point you intend to be making with this paragraph.

821 and 822 have gone through multiple significant changes since they were first published. So it isn't as if making some changes to them has never been done before.


At least IMO and although I can name exceptions, the IETF has
almost always done better (in terms of quality and wide
adoption) with new protocols, especially ones that fill a
vacuum, than with revisions to long-established ones.  Maybe

Filling a vacuum is always easier and generally safer than displacing something. Installed base being messy, and all that.

But, umm... So you think revision of TCP's re transmission mechanism, after 10 years of operation, didn't go well? Or that adding options to SMTP didn't go well? Or fixing the security mechanism for SNMP didn't go well? Or that pressing to require SMTP to run over TLS hasn't gone well? Or...


that is how it should be but, if we are going to make revisions
to widely-deployed protocols, especially revisions that imply
that people should (or MUST) do things differently, I think
doing something differently than what it is perceived we have
"always" done may be entirely appropriate lest people look at
our work and paraphrase the comment about doing things the same
way multiple times that is attributed to Einstein.

Don't bis or ter documents pretty much always include parts that /change/ rather than just add?

More generally, I'm not understanding the point of that paragraph.



The established terms are actually rather precise and refer to
the
networking abstraction, not an implementation.

Good luck trying to get everyone to use these or any other
terms, in exactly the way you want them to use them, on any
particular occasion.

Forgive me. I thought this was a technical forum and that as technicians we tend to value reliability and precision in terminology.

The view you espouse does make things easier, though. For one thing, it means that specifications can skip the part where they define terms, since apparently no one will use them as defined.


If we are going to treat RFC 5598 and/or the discussions that
led up to it as final and normative,

You mean treat it as if it were the IETF-approved consensus document it actually is? Seems risky.


           or even "as established
terms" and therefore align 5321bis (or any subsequent document)
with what it says (or appears to say), then let's do what my
reading of RFC 2026 requires, which is to put 5321bis aside for
a while and issue a 5598bis as a PS or BCP that makes clear
which sections or terminology of 5321 it is updating or
replacing, then come back to 5321bis.  I think a better

Interesting. What's easy to miss is that the parts of RFC 5321 that RFC 5598 "updates" are parts of RFC 5321 that are larger architectural issues that are outside the basics of the transfer of mail between MTAs and received more recent, detailed, and community-vetted discussion in RFC 5598.

That is, by removing these extra parts of the SMTP document, we get a much more focused document AND it doesn't collide with RFC 5598, and can call on RFC 5598 for context.

There's a common challenge in the reference and incorporation relationship among document collections. Simplistically put: which way do the arrows point?

If this is not answered carefully, the result is that readers bounce back and forth and maybe get confused, but also the result is a maintenance nightmare.

Consider:

1) Point down
                      +---> Specific 1
      Architecture  --|
                      +---> Specific 2
                      |
                      +---> ...

2) Point up
                      +---  Specific 1
      Architecture <--|
                      +---  Specific 2
                      |
                      +---  ...

3) Point Everywhere

                      +---> Specific 1
      Architecture <--|
                      +---> Specific 2
                      |
                      +---> ...

Now change the document Specific 2 and think about what needs to be updated for each model.

Then to make it more interesting, consider what happens if 1 or 3 applies to a collection of different documents referencing each other in the set.

That is, clean, downward-pointing references tend to produce simpler use and simpler maintenance.


strategy, and more consistent with IETF practices in which no
document is so much the last work on a subject as to make it
never subject to future debate or revision, to treat 5588 as
useful guidance as we undertake 5321bis but with the

Most IETF documents are little more than useful guidance, including the ones labeled standards track.

So if things have changed since RFC 5598 obtained approval and there are changes to the document that you deem necessary, what are they?


understanding that the terminology and models of 5321, 5598, or
even something else may ultimately prevail.

Yes indeed. Always appealing to re-litigate, especially without any apparent and substantial basis.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>