Hi.
I am opposed to publication of this document on the standards
track. I believe that it should be published, but as an
Informational or FYI document with an IESG statement that
stresses that it represents a consensus description of the
Internet email model, that other descriptions are possible, but
that the document is not a Standard and not normative in any
way. If the IESG also wanted to make a statement indicating
that the terminology in this document would be required for
_new_ protocol specification in the email area, I think that
might be an acceptable compromise for those who believe that is
the document's purpose.
I do not consider that an ideal solution. I think documents
like this one strongly suggest that our categories of Proposed/
Draft/ Full Standard, BCP, Experimental, Informational, and
perhaps FYI are not well-suited to all of the documents
circumstances we regularly encounter and that it is time to
review and revise those categories. But I don't believe the
community would be well-served by blocking this document until
that work is done.
My opposition to Standards Track is based on several concerns.
Any one of these would, in my opinion, call standards-track
publication into question. The main argument I see for
standards-track publication is that it would give the document
greater authority. However, I believe that level of authority
is not justified, that it would be problematic in other ways,
and that the document is not quite ready for it.
The most important of those concerns are:
(1) Publication of a retrospective "architectural" document
as a standard is inherently problematic. It is not a
specification or model for how to do something, but a
retrospective description of what exists. Even though it
might be used to shape future developments and protocols, it
remains a retrospective description -- an attempt to impose
a model where none really exists with strong consensus-- not
a forward-looking architectural specification.
(2) This is not a protocol specification. As a Proposed
Standard, there would be no model for interoperability
testing or examination of deployment unless it were compared
to implementations of the existing standards-track protocol
specifications. And we know that it would fail such a
comparison, at least in some details.
(3) I believe that the community has significant experience
that, no matter what disclaimers appear in the document, its
publication on the standards track will be used to argue
that other standards are "wrong". Whether that leads to
demands that any modifications of those standards be brought
into compliance with this document or is used as an argument
for partially disregarding whatever they say, that would be
a problem. The new introductory material reduces this
problem somewhat, and it might occur even with an
informational document, but I believe that not having it
identified as a standard would significantly reduce the
scope of the problem.
(4) If this were to be published as a standards-track spec
despite the reasoning in the rest of these comments, I
believe it should explicitly call out differences in
terminology or concepts from existing standards-track
protocol specifications and discuss those differences. To
do otherwise invites more, rather than less, confusion.
(5) The extensive discussions on the ietf-smtp list and
elsewhere since the first Last Call was initiated suggest
that there are still significant disagreements in the
community about the accuracy and applicability of the model
and about the terminology used, especially with regard to
administrative boundary issues and handoffs. I think that
each of those could be resolved in some way (possibly by
explicitly documenting the differences and rough edges), but
that doing so would not be worth the added effort relative
to the advantages of getting the document published sooner,
rather than later. However, if the document is going to be
published as a consensus standard, rather than as a
description, I believe that those issues do need to be
addressed and settled, one at a time, probably via a WG
process.
For the information of the community, I sent a much longer and
more extensive analysis of the situation as I saw it to the
IESG some time ago. Since that discussion has been circulated
privately beyond the IESG, I don't see any further advantage in
treating it as confidential. I have attached that note to this
one for further reading by anyone who wants to do it, but I
believe the notes above constitute a reasonable summary. In
particular, the attached notes have been interpreted as a
suggestion from me that the document not be published at all.
That is not the case: I think it is more than useful enough to
be published, just not on the standards track. I also do not
believe that the investment of significantly more effort in it
would yield a significant payoff even though I believe that
effort is required for a standards-track document that will not
progress further.
regards,
john
--- Begin Message ---
Hi.
Given that cluttering this discussion with the tradition of a
long-standing feud between Dave and myself would not help anyone
and that most of these comments are ultimately procedural rather
than specific technical criticisms, I've decided that the
circumstances are "exceptional" and hence am sending this
directly to the IESG. I do not believe that any of the
comments in this note will be a surprise to any of the people
who have been most active in getting the subject draft together.
I have no objection to the IESG making the note public if you
conclude that doing so would be in the best interests of the
community.
First, this document continues to improve. The first Last Call
caused sufficient changes to require a second Last Call.
Discussions after that one caused further substantive changes.
Some of those changes are, themselves, controversial enough to
have stimulated significant additional discussion from people
who are sensible and well-grounded in Internet email systems (as
well as from a few who may be less grounded and/or qualified).
Most of those discussions have occurred on the ietf-smtp list.
The advantage of having discussions there is that it has kept
the discussions off the main IETF list and thereby avoided
contributing to what, from the standpoint of most of the
community, would be noise on that list. The disadvantage is
that it has largely hidden from IESG members who do not follow
that list just how much controversy remains about this document
and how much discussion is ongoing about it (much of it
non-converging).
The latest version (to be posted today, I believe) represents a
further improvement, but is sufficiently different from the
previous ones to suggest that yet another Last Call would be in
order. I do not believe that is in the best interest of the
community because discussion of the document draws energy away
from other work and that stretching it out could easily lead to
consensus by attrition as those who do not believe they are
making progress wander away in frustration. There is an
alternate proposal below.
There are, I believe, three fundamental controversies with this
document. At least two of them are sufficiently fundamental
that no amount of document tuning is really going to resolve
them and create consensus instead, even though it might reduce
the pain:
(1) The document is written to be normative and prescriptive but
is inconsistent with a number of basic protocol documents (in
part because they are inconsistent with each other). Even if it
contains disclaimers --for existing documents or going forward--
it is inevitable that the differences in terminology and model
will cause confusion in the broader community, lead to
discussions about where the protocol standards are "wrong" and
the architectural one is "right" (or vice versa). Such
confusion benefits no one and, in the email world, has often
been used to justify bad behavior. The new disclaimer text
improves on the situation for those who read the documents
carefully, in context, and with good intent, but will do nothing
to help with those who either want to justify behavior that is
inconsistent with one set of specifications or the other or who
wish to impede progress by insisting on conformance with the
language and model of the architectural document.
(2) It is a reality that there are fundamental differences in
perspective about Internet mail and the underlying models. One
of these is actually at the technical root of the ancient
disagreements between Dave and myself. With the understanding
that I'm oversimplifying both views, one is that the important
part of the model is the transport mechanisms that actually get
the messages across the network and delivered. Consequently,
what appears in headers, etc., is just metadata, some
flexibility of interpretation and actions at the endpoints is
appropriate and we should be looking at things primarily in
terms of the transport and what happens on the actual wire and
what affects that. The other view is that the headers and
message formats are important, the transport is relatively
unimportant --no more important than, say, the details of TCP to
an application-- and that our focus should be on the message
before and after the transport process, with the latter
important only to the extent of getting something across the
network.
The differences get especially important when one starts talking
about gateways between more or less disparate email systems and
about extensive relaying (at the behest of either the sending or
receiving system). They are less important in practice with
initial-point-to-destination-point Internet mail.
We have successfully gotten through the last quarter-century or
more, not by ignoring these differences but by keeping them in
healthy tension, trying to allocate functions between them, and
creating a certain amount of interpretation "slop" that has
contributed positively to interoperability. When something can
be handled differently according to the different perspectives,
we've tended to have acrimonious arguments but to be able to
sort things out, largely because no one can really point to a
higher authority.
The difficulty in this situation is that this architecture
document is clearly written from one of those perspectives. The
other perspective has been dismissed, sometimes fairly abruptly.
If we standardize the one perspective, it is inevitable that it
will be cited as an authority to "settle" the decisions about
how some new capability should be handled without the healthy
discussions that have occurred in the past.
Again, we have not been able to reach consensus on which of the
two approaches is "correct" for the last quarter century. I see
that as a problem only if the intent is to publish
draft-crocker-email-arch as a normative consensus document.
(3) Partially because no one could come up with anything better,
the document uses some terminology that is drawn from other
contexts, contexts in which that terminology has very specific
meanings and/or some semantics that are inappropriate for
Internet mail. Because people often tend to read long
documents quickly, looking for information, rather than
beginning to end and keeping all local definitions in mind, this
can be a source of additional confusion and, in the long term,
contention. Perhaps the worst example of this is "ADMD" which,
in ISO MHS/X.400-land, has a very specific meaning that implies
both government authorizations and direct ADMD-ADMD handoffs
with formal bilateral arrangements. But there are others.
Conclusion and Recommendation: While Pete's new disclaimer text
helps quite a bit, one can imagine ways to improve it further,
point out some of the issues and differences above in a clear
way in the document, and perhaps even further tune the document.
It could also, in principle, be rewritten from a prescriptive
form to a descriptive one (far more appropriate to what we
usually think of as an "architecture" document), but I believe
that change would be violently opposed by several of those who
have contributed to the document.
I think we are past the point of diminishing returns and that
the amount of energy required to "fix" the document far exceeds
the likely value of the improvements... and that assumes that
consensus could be reached, which I believe is unlikely.
This document should be published, but it should not be
published in a way that gives it even the appearance of formal
normative status. Instead, it should be published either as
Informational (possibly taking advantage of the new provisions
in "headers-and-boilerplate" to specify that it does represent
IETF consensus _as a description_ or, if the IESG wants to bring
out an old category that we have never quite retired, as an FYI
(those documents are, by definition, consensus documents that
are descriptive, rather than normative). It would also be
desirable to reconsider the title in the light of the comments
above. Something like "An Overview of the Internet Mail Model"
would be much more clear as to role and purpose than
characterizing it as _The_ Internet Mail Architecture (emphasis
added).
Thanks for listening.
regards,
john
--- End Message ---
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf