Subject: Re: More information requested on publication status of draft-crocker-email-arch

From: John C Klensin <[email-masked]>
Date: Thu, 28 May 2009 14:27:28 -0400

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

Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
From: John C Klensin <[email-masked]>
To: [email-masked]
Date: Fri, 15 May 2009 15:27:05 -0400

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 May 2009 13:17:51 -0700

[[ I'm not picking on John: I could have sent this reply to any of the messages on the thread. ]]

At 2:27 PM -0400 5/28/09, John C Klensin wrote:
>our categories of Proposed/
>circumstances we regularly encounter

Of course. This is clear to folks at all levels of experience in the IETF.

> and that it is time to
>review and revise those categories.

...and expect a different outcome than our most recent attempts? The previous attempts did not fail for lack of participation from enough concerned people, nor from the lack of workable ideas: they failed due to lack of energetic agreement.

A different idea is for the IETF Leadership to say "in May 2011, we will start the Newtrack++ effort, and we won't start it before then". In every troublesome case in the next two years, the IETF community agrees to do a group shrug, make notes, and move on. Two years from now, those whose shoulders do not hurt from too much shrugging can make another run at fixing the process.

Permanent repetitive process work does not lead to good results for the organization or for the individuals who get wrapped up in the work.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 May 2009 17:39:34 -0400

--On Thursday, May 28, 2009 13:17 -0700 Paul Hoffman
<[email-masked]> wrote:

> ...and expect a different outcome than our most recent
> attempts? The previous attempts did not fail for lack of
> participation from enough concerned people, nor from the lack
> of workable ideas: they failed due to lack of energetic
> agreement.

In fairness, I cannot remember when there been a serious
discussion about adding or redefining categories, even though
there have been many discussions about how many maturity levels
we need in the standards track and a few about whether we should
be using "BCP" for internal processes documents.

> A different idea is for the IETF Leadership to say "in May
> 2011, we will start the Newtrack++ effort, and we won't start
> it before then". In every troublesome case in the next two
> years, the IETF community agrees to do a group shrug, make
> notes, and move on. Two years from now, those whose shoulders
> do not hurt from too much shrugging can make another run at
> fixing the process.
> 
> Permanent repetitive process work does not lead to good
> results for the organization or for the individuals who get
> wrapped up in the work.

While I agree, I would also point out that attempts to get
process moratoriums declared have not been successful either.
We were, IMO, badly in need of one after the Newtrk meltdown but
have since had a long and painful IPR process and debate (not
over yet, apparently), a few rounds of debates about
boilerplate, several efforts to fine-tune the Nomcom, the
various pieces of the RFC Editor Model and new RFP (&c.)
processes, plans about changes in RFC and I-D formats, about
revisions to RFC 3932 and related procedures, and even about the
criteria the IAOC uses to pick meeting locations and how it
involves the community (or not) in the selection of  those
criteria.  Some of these things are related  to some of the
others in ways that make working on some of them without the
others questionable at best.

In addition, that shrug of the shoulders isn't just a shrug --
it requires making difficult decisions about how to handle
things and assign them to categories when none of the categories
are an exact match, selecting meeting locations, formatting I-Ds
and RFCs, etc.

So, while I would be in favor of the time out you propose, I'm
in favor of it only if it is comprehensive and that we don't end
up having AD encouragement or agreements to push through "just a
few" process-related changes.  Experience tells me that is
unlikely, but I'd be happy to be wrong.

    john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 29 May 2009 09:39:20 +0200

On 28 mei 2009, at 23:39, John C Klensin wrote:

> plans about changes in RFC and I-D formats

Huh?

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 29 May 2009 06:18:42 -0600

>From ASCII to UTF-8, or from plain-text to PDF.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 May 2009 08:38:38 -0400

> From ASCII to UTF-8, or from plain-text to PDF.

Or the more recent, long and with many messages, discussion
about the order of the abstract and other boilerplate.

How soon we forget.

    john