Subject: IETF Standards Process

From: Dean Anderson <[email-masked]>
Date: Tue, 3 Jun 2003 17:28:55 -0400 (EDT)

You indicated that my criticism was incorrect regarding Mr. Klensin's
understanding of the standards process in regards to the description of
the current SMTP Standard.  So, now I am confused, and would like to learn
how to correctly evalute the status of IETF Standards.

The following question seems simple enough:

"What is the current standard level RFC describing the SMTP protocol?"

I see that RFC Index lists RFC 821 as being obsoleted by RFC 2821.

However, RFC 2821 status is "Proposed Standard", which is not a
standard-level RFC, according to the Standards Process documented in RFC
2026. Indeed, RFC 2821 was dated April 2001. Section 6.2 of RFC 2026
indicates:

When a standards-track specification has not reached the Internet
   Standard level but has remained at the same maturity level for
   twenty-four (24) months, and every twelve (12) months thereafter
   until the status is changed, the IESG shall review the viability of
   the standardization effort responsible for that specification and the
   usefulness of the technology. Following each such review, the IESG
   shall approve termination or continuation of the development effort,
   at the same time the IESG shall decide to maintain the specification
   at the same maturity level or to move it to Historic status.  This
   decision shall be communicated to the IETF by electronic mail to the
   IETF Announce mailing list to allow the Internet community an
   opportunity to comment. This provision is not intended to threaten a
   legitimate and active Working Group effort, but rather to provide an
   administrative mechanism for terminating a moribund effort.

I can find no reference that RFC2821 is a Standard, and it would seem that
it has remained at the same maturity level for 24 months or longer.
Thus, it seems to be appropriate that the IESG should review the viability
of the standardization effort, and decide if the effort should be
terminted or continued.

I also see that I am not the first to criticize the RFC 2821 effort
(http://cr.yp.to/smtp/klensin.html

I see that RFC 3300 indicates that RFC 821 is currently listed at STD 10.

How could RFC 821 be obsolete if it is STD 10?  Is this an error by the
RFC editor in the RFC Index?

I also note that RFC 3300 indicates a status change on RFC 2821 to
"proposed standard" by use of an asterisk. However the previous verions
(RFC 3000) indicates that RFC 2821 was in state "proposed standard" then
too. There seems to be no status change. Is this an error?  What was the
status change indicated in RFC 3300?

So, does that mean that I am wrong that RFC 821/STD 10 is the current
standard for SMTP?

It seems to me that RFC 2026 supports my view, that the current SMTP
Standard is RFC 821, though there are inconsistencies in the IETF process
documentation that might suggest or lead one to conclude otherwise.

I note that similar issues appear to exist with RFC 2554, but that is it
dated March 1999.

If these RFCs are not in fact Standard Level RFC's, it is inappropriate
for persons associated with the IETF to describe them as such, and
therefore this seems to be a violation of section 4 of RFC 3184, Code of
Conduct, for having not read the RFCs.  On the other hand, perhaps I have
missed something or otherwise misunderstood those RFCs, and am myself in
violation of section 4.  I seek guidance on this issue.

Thank you for your attention.

Dean Anderson
President, Av8 Internet, Inc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Jun 2003 07:48:13 +0200

> "What is the current standard level RFC describing the SMTP protocol?"

formally, we have two standards-track specifications for the SMTP protocol.

RFC 821 at Standard, and RFC 2821 at Proposed Standard.

The intent is, I believe, that any RFC 2821 client will be RFC 821 
compatible, but implementors who care should state which specification they 
claim conformance to.

The "delete after 24 months" clause of RFC 2026 is inoperative in practice; 
the oldest Proposed Standard is RFC 698, published in 1975.

I have no explanation for the error in RFC 3300; the RFCs in question were 
published by the RFC Editor without IETF review.
The first such document to refer to RFC 2821 was RFC 2800.

                   Harald

---

From: Dean Anderson <[email-masked]>
Date: Wed, 4 Jun 2003 11:54:03 -0400 (EDT)

inline. I apologize in advance for so many questions. I have looked on the
ISOC site, and IAB site, and other pages to find the answers to these
questions.

> RFC 821 at Standard, and RFC 2821 at Proposed Standard.

4.2.4  Historic

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.  (Purists have suggested that the
   word should be "Historical"; however, at this point the use of
   "Historic" is historical.)

   Note: Standards track specifications normally must not depend on
   other standards track specifications which are at a lower maturity
   level or on non standards track specifications other than referenced
   specifications from other standards bodies.  (See Section 7.)

Does RFC 2821 make up part of STD 10?  It seems confusing, since STD 10
depends on RFC 821 which has been obsoleted by RFC 2821. By inference it
seems that STD 10 includes RFC 2821.  Does this violate Section 4.2.4 of
RFC 2026?

Has RFC 821 been superceded by RFC 2821? If not, then how can RFC 821 be
obsolete?

It is confusing for RFC 821 can both be at "Standard" level and also
"Obsolete". Is the "Obsolete" notation on RFC 821 an error?

Further, RFC 2026 Section 4.1.1 recommends that "Proposed Standards"
should not be deployed into a "disruption-sensitive environment":

4.1.1  Proposed Standard

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.  However, the IESG may
   waive this requirement in order to allow a specification to advance
   to the Proposed Standard state when it is considered to be useful and
   necessary (and timely) even with known technical omissions.

Bradner                  Best Current Practice                 [Page 12]

RFC 2026               Internet Standards Process           October 1996

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

Our business customers with mission critical service requirements would be
concerned about using software which is not recommended for
"disruption-sensitive environments".  Does the IETF recommend ignoring its
own warnings?  If so, why have them?  Do you think that introducing
"Proposed Standard" implmentations into disruption-sensitive environments
despite the warnings regarding use of Proposed Standards violates section
4 and section 14 of the ISOC Code of Conduct?

> compatible, but implementors who care should state which specification they

The criticisms documented by Dan Bernstein seem to suggest there are
considerable incompatibilites.

Implementors are not the only users of standards.  Businsess seek to
purchase and sell "Standard" Services, and may receive just and public
criticism for not providing the services they claim to provide. In some
jurisdictions, this could conceivably be considered fraud, and/or unfair
trade practices.  So if a business (SMTP client vendor, SMTP server
vendor, ISP, etc) claims to provide "Standard SMTP Service", and comply
with the "SMTP Standard", to which RFC should they be held accountable?

> the oldest Proposed Standard is RFC 698, published in 1975.

If there is not agreement on the IESG (since 1975) to move an RFC to
"Draft Standard", nor to "Standard", then perhaps work on this proposed
standard should be terminated, and the proposed standard should be made
Historic, so that in the case of RFC 698, Telnet implementors are not
confused with irrelevant and inapplicable standards. Does this violate
section 4 and section 14 of the ISOC Code of Conduct?

Is the failure to carry out the procedures documented in RFC 2026 a
failure of either the IESG or the IAB?  Is this a failure of the ISOC to
facilitate the legal and organizational issues concerning its conduct as
described in RFC 2031?

> The first such document to refer to RFC 2821 was RFC 2800.

Should the text RFC 3300 be updated to eliminate this error?  Is it
possible that the maturity status of RFC's could be changed by error?

Thank you for your attention,

Dean Anderson

---

From: [email-masked]
Date: Wed, 04 Jun 2003 13:57:00 -0400

> with the "SMTP Standard", to which RFC should they be held accountable?

Given that the Cisco PIX claimed to have an SMTP implementation from the
very beginning, and they still sold lots of them, I don't think there's much
chance of leveraging a lawsuit over the distinction between 821 and 2821.

(For those not familiar with the early PIX software, the best that can be
said about it is "near-universal derision".  Cisco has, to its credit, fixed
all of the glaring bogosities that I'm aware of, so the current release of
software *is* at least a "plays well with others" SMTP).

---

From: Dean Anderson <[email-masked]>
Date: Wed, 4 Jun 2003 14:43:05 -0400 (EDT)

You made my point. Cisco was "justly and publicly" criticized with
"near-universal-derision" for not complying with the standard.  Most
companies want to avoid that.  False derision is actionable in many
jurisdictions.

		--Dean

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 05 Jun 2003 20:52:43 +0200

> ISOC site, and IAB site, and other pages to find the answers to these

since most of your questions can easily be answered "no", I don't see the 
point of going into details.

The "Obsoletes:" header is a protocol that is too weak to carry the full 
semantics of the relationship between documents.

Proposed Standards are being used in the real world, for reasons that the 
users of those standards find sufficient.

RFCs are never changed.

ISOC's code of conduct bullet 4 says:

>Avoid deploying technologies that defeat generally accepted technical 
>principles of the Internet, as documented primarily by the Internet 
>Engineering Task Force (IETF). In particular, avoid technologies that tend 
>to subdivide access to the Internet rather than preserving its universal, 
>unique, and international nature, except as required by security 
mechanisms >mentioned in the next paragraph

It is our fervent hope that we do not publish Proposed Standards that 
defeat generally accepted technical principles of the Internet.

                     Harald