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

[Dave Crocker <[e-mail]>]

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