Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

John C Klensin <> Sat, 14 June 2008 01:14 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id BDE593A68CB; Fri, 13 Jun 2008 18:14:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 561823A68CB; Fri, 13 Jun 2008 18:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r3Sj78arTuo2; Fri, 13 Jun 2008 18:14:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 386E93A6849; Fri, 13 Jun 2008 18:14:09 -0700 (PDT)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1K7KLo-000K8O-1R; Fri, 13 Jun 2008 21:14:41 -0400
Date: Fri, 13 Jun 2008 21:14:38 -0400
From: John C Klensin <>
Subject: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Message-ID: <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Executive Summary

draft-klensin-rfc2821bis completed IETF Last Call for approval
as Draft Standard and was placed in "IESG Evaluation" state on
May 1st.  IESG positions about it were first recorded on May
5th.  Several minor technical issues were quickly resolved.
However, an AD has entered a DISCUSS on the basis that examples
used in the document contain domain names which are not among
those reserved in RFC 2606 (BCP32).  The text of that document
does not require the use of those names; it only reserves them
and makes them available for use.  There is no requirement to
use RFC 2606 names in any other BCP or even in any
IESG-published statement (the relevant statements and textual
details are included in the detailed discussion below).
Attempts to discuss the issues with the AD, including efforts
to offer explanations as to why the editor and developing group
selected the names that are in use, have been unsuccessful; the
AD has made it clear that the DISCUSS is blocking and that the
only choices are to revise the document to match his
preferences, to appeal, or, presumably, to withdraw the
document entirely.

Use of a DISCUSS in this way unnecessarily and unreasonably
blocks document progress, discourages efforts to advance work
in the IETF, and is inconsistent with the IESG's own statements
on the appropriate use of DISCUSS positions.  It is not
mandated or supported by any IETF or IESG documentation and
represents an abuse of AD authority for which there is no
effective remedy within current normal procedures.  The
existence of this situation demonstrates that those normal
procedures are inadequate or insufficient to protect the rights
of all parties in a fair and open Internet Standards Process.

This appeal seeks relief both for the specific situation and
for the procedural inadequacies that enable it.  

This document is somewhat more detailed than appeals in the
past because most of the issues involved are consistent with
those covered in RFC 2026, Section 6.5.3, i.e., that the IETF's
procedures appear to be inadequate or insufficient to protect
rights to a fair and open Standards process.

Remedies Requested

(1) The blocking DISCUSS must be removed.

	No one objects to a reasoned discussion on the issues.
	However, a blocking DISCUSS in this type of situation is
	more than inappropriate; it is harmful to the IETF. 

(2) Either by developing separate terms or through some other
mechanism, the IESG must clearly differentiate, at the time
positions are registered, between a DISCUSS intended to raise a
question or initiate discussion and one that is intended to
block the document if not resolved to the AD's satisfaction.

	Although "DISCUSS" has been in use, with slight variations
	in definition, since the IESG assumed responsibility for
	approving IETF documents, the DISCUSS construct is purely
	an IESG creation.  There is no consensus document which
	specifies IESG voting procedures or categories or that
	otherwise requires a DISCUSS or prohibits more nuanced
	positions.  Distinctions between blocking positions and
	those representing questions, comments, or advice should be
	made clear in the document tracker and other appropriate

(3) To protect the rights of all parties to a fair and open
Internet Standards Process that is free of abusive behavior, of
unnecessary and inappropriate "late surprises", and of
imposition of novel requirements during the review process, the
IESG should modify its rules to prohibit the use of a blocking
DISCUSS on a specification for any editorial or other
non-technical reason unless the requirement is clearly
documented, either in (i) a BCP or (ii) a formal position or
procedural statement that is subject to appeal at the time of

	The IESG's current "DISCUSS Criteria" prohibit the use of a
	DISCUSS to block a document for an editorial or stylistic
	reason, but that rule is not being followed. In either
	case, the document that specifies the stylistic or
	editorial rules must be published and widely available
	prior to the time the specification enters Last Call.

(4) The IESG should explicitly recognize that the interests of
the IETF and the Internet community are served by encouraging
the advancement of documents in maturity level on the standards

	To that end, while authors, editors, working groups, and
	the community should welcome suggestions for improvements
	in the editorial quality of documents proposed for
	advancement, the IESG should be prohibited from requiring
	changes that are not tied to substantive technical issues
	with the original document, clarifications (including
	improvements to readability and comprehensibility), or
	interoperability.  Specifically the goal for revising
	documents seeking advancement along the standards track is
	to preserve as much community experience with the earlier
	version(s) as possible consistent with accuracy and
	clarity.  Hence, no changes should be sought except those
	deemed essential to the utility of the document.

As will be discussed in detail below, simply removing the
DISCUSS on the document will not satisfy this appeal. This
appeal raises questions of applicable procedure and the
openness and fairness of the Standards Process which must
be addressed as part of the response to it.

Background and Details

draft-klensin-rfc2821bis (referred to just as "2821bis" below)
is a revision, intended for Draft Standard, of RFC 2821 which
is, in turn, a consolidation and update of the Internet's base
standards for email transport (collectively known as "SMTP")
and first documented in RFC 821, more than 25 years ago.  The
examples in question in the current draft were in the original
specifications or are minimal changes to those original
examples approved by a WG and published more than seven years
ago. The original examples have apparently caused no problems
for a quarter of a century.  RFC 2821, and consensus about its
content, wording, and organization, was the result a diligent,
multi-year effort by the DRUMS Working Group.  2821bis differs
from RFC 2821 only by incorporating a series of clarifications
and corrections of errors.  With both RFC 2821 and 2821bis,
great care was exercised to avoid unnecessary changes lest they
have unanticipated and disruptive side-effects on the installed
base or introduce new forms of confusion.  While 2821bis is not
the product of a formal WG, it results from extensive mailing
list discussions of substantially every change.  These
discussions included many long-term contributors to Internet
email technology and standards as well as most other active
DRUMS participants, and further including several people who
have more recently become involved in IETF processes and email

It is worth noting that, aside from ongoing discussions about
whether SMTP and email generally work too well --well enough to
enable spammers and other abusive behavior-- the continuing use
of Internet mail by perhaps one billion people, based on many
different implementations of each functional component of the
mail service's architecture means that the existing
Standardized specifications are obviously sufficient to enable
conforming interoperability.

There is now an impasse about how, or whether, to proceed with
2821bis.  An AD has generated a DISCUSS about changing all of
the examples that do not use RFC 2606 names (e.g.,
"" and equivalent) to use that convention, with the
possible exception of those that point to ISI or USC.  He has
indicated that he does not intend to remove the DISCUSS until
the examples are changed (the exact statement, in a note sent
05 June 2008 09:50 -0400, was:

	"As I said in the second paragraph of the previous response.
	The IESG has been enforcing the BCP for at least five
	years.  I await a revised document or an appeal.  That
	choice is yours.").

The IESG has not chosen to use the override procedure specified
in its specifications for handling DISCUSS ballots. 

The DISCUSS does not, in practice, appear to be a request for
an actual discussion.  There has been fairly extensive
correspondence on this subject, but editor explanations as to
why it is, on balance, inappropriate to change the examples
have been rejected without any substantive comment, although
there have been a few statements of the AD's beliefs.

The key to this appeal is that neither RFC 2606, nor the
IESG-produced "Guidelines for Authors of Internet Drafts"
[], nor even the
IESG-produced "Internet Draft Checklist" ("IDNits")
[] require use of the 2606
names.  RFC 2026 (BCP 9), the defining document for IETF
Procedures for advancement of specifications on the Standards
Track, is silent about this type of issue, focusing on
technical maturity and interoperation.  RFC 2606, which is the
only consensus document on the subject, says things like "can
be used" about these names.  It does not even express an
explicit preference for their use.

There are three IESG position statements that might bear on the
issue.  There is apparent community consensus that the IESG can
use its discretion to specify details of document handling that
are not explicit in RFC 2026 and the documents that update or
modify it.  In recent years, the IESG has, with considerable
community encouragement, chosen to write its current procedures
and criteria down in IESG Statements and other documents.  When
the IESG has done so, and conformed to its own statements and
criteria, there has been an overall improvement in the
efficiency of the overall IETF process, both reducing the
chances of last-minute delays to documents resulting from
surprising authors with new rules late in the process and
reducing the community perception that the IESG behaves
capriciously.  The present appeal responds to an IESG action
that appears to counter both of those positive trends.

(1) The "Guidelines to Authors of Internet Drafts"
( does not mention
the issue of examples at all.

(2) The I-D Checklist (IDnits,, Section 6, says

        "Addresses used in examples SHOULD preferably use
        fully qualified domain names instead of literal IP
        addresses, and preferably use example fqdn's such as instead of real-world fqdn's."

"SHOULD preferably" and "preferably" are, I believe obviously,
statements of preference, not firm requirements.  That is
especially true of the second one, which doesn't even contain
the word "SHOULD".

(3) The DISCUSS Criteria document
does not list the use of non-2606 names as an item on the list
of criteria in Section 3.1.  Indeed, it explicitly prohibits,
in its section 3.2, DISCUSSion for "Pedantic corrections to
non-normative text" and "Stylistic issues of any kind".

The AD holding the DISCUSS has indicated that he doesn't like
these names and considers their use "rude".  His other
justification is that he states that the IESG has been
enforcing the use of RFC 2606 names as a firm rule for "at
least five years".

The position taken by this appeal, which we hope will be
upheld, is that, in general,

	(i) It is not appropriate or permissible for the IESG to
	invent rules that are then used to block progression of a
	document without consulting the community.

	(ii) It is inappropriate, and a violation of the principles
	that ensure a fair and open process, for the IESG to make a
	clear statement of the conditions under which it will block
	a document (as it has done in "DISCUSS Criteria") and then
	to apply rules on final review that are at variance with
	those conditions.  Put differently, the obvious purpose of
	IESG statements about the rules it will follow is to inform
	the community about what should be done to avoid having
	documents blocked whenever possible.  When the IESG does
	not follow its own stated rules, a fair and open Internet
	Standards is compromised.
	(iii) Given the pressure on authors --especially WG
	Chairs and document editors-- to simply go along with AD
	demands and preferences, reasonable or not, in order to
	get documents published rather than permanently stalled,
	it is not plausible to assume that "the IESG has been
	doing this for years" constitutes evidence that the
	community has approved of the IESG's doing so.
	(iv) Even if one were to concede that the IESG has the
	authority to make the use of the 2606 reserved names a
	requirement, it is abusive --an example of a completely
	unnecessary and very late review "gotcha" surprise-- for
	the IESG to impose it without documenting it in any of the
	criteria statement documents identified above.  If the IESG
	wants to impose rules like this, it should move to revise
	one of more of the procedural documents (presumably the I-D
	Checklist) to specify the requirement.  It should publish
	that revised form and see if the community accepts that
	additional rule once it is written down.  Of course, the
	IESG could also initiate an update to RFC 2606 that changes
	"can be used" into "MUST be used unless the IESG grants a
	waiver".  Both of those suggestions were made during
	attempts to actually discuss the "DISCUSS" position.  There
	has been no response to either suggestion.
	(iv) Since this blocking DISCUSS is inconsistent with the
	IESG's published statements about conditions for such
	actions (in the absence of a mandate from a consensus
	document, it appears to be an "editorial preference") and
	there seems to be no practical way to un-block it, it is a
	case in which, excerpting from RFC 2026, Section 6.5.3,
	"the procedures themselves ... are ... inadequate or
	insufficient to the protection of the rights of all parties
	in a fair and open Internet Standards Process".  Even were
	the IESG to withdraw the DISCUSS during the appeal process,
	the question of whether the use of a DISCUSS in this way is
	consistent with a fair and open process would remain and
	would be fundamental to the appeal.

	(v) There have been many discussions over the years about
	why the IETF advances so few documents past Proposed
	Standard.  This incident has made it clear that one of the
	many reasons is IESG behavior: the more obstacles that are
	placed in the path of advancing documents, the fewer
	attempts will be made to advance them.  It is obvious that
	making revisions to a document to improve its quality risks
	introducing new errors or new confusing text and that each
	such change introduces more burdensome requirements for
	review to be sure that problems are not introduced.
	Consequently, once the IESG has already approved a document
	(even at Proposed Standard, but especially when documents
	at Full Standard covering much of the same material always
	exist), it should not introduce requirements for new
	changes unless those the requirements are either clearly
	documented or are motivated by technical considerations
	that are clearly problematic.  Put differently, when a
	document is being revised and updated, imposition of
	stylistic, organizational, or presentation requirements
	that were not in effect when the original document was
	approved should require strong and substantive
	justification that balances the advantages of change
	against the costs and risks of delay and disruption, not
	merely a preference or statement about what is done with
	new documents.

	Quoting from one of the comments made when the issue was
	discussed on the mailing list: "When revising a document,
	the cost of the revision should be commensurate with the
	community need for the changes.  RFC2821bis is a very small
	effort to make minimal changes to a successful document.
	It is simply not reasonable to start imposing more recent
	requirements -- assuming they really are valid requirements
	-- absent a compelling demonstration of damage that will
	accrue without the change."

Slightly recasting another on-list comment, if the IETF is to
make effective progress on standards, it must operate without
having the personal, non-technical preferences and perspectives
of IESG members used to dominate IESG decision-making.  To
permit these preferences to hold sway deprives the community of
a stable, fair and open process.  Consistently, the IESG seems
to choose DISCUSS over the other available choices, and DISCUSS
serves to seriously delay documents, while the other choices
allow it to continue through the process. The present DISCUSS
is an example of this. Instead of sending a comment back to the
author saying, "The IESG believes that the examples should use
the 2606 recommendations" and let the document progress while
the author works that out (or decides not to), the IESG felt
that publication of this document as-is would be so harmful
that it deserves to be stopped in its tracks. "That's just

I note that, while the present situation and 2821bis constitute
particularly glaring examples of these misplaced priorities and
abuses, none of the issues above is unique to 2821bis.  They
are really about how the IESG manages and expresses its
authority and discretion.  

There is one more general issue: which is clarity about what
changes are reasonably demanded of a document being progressed
from one
maturity level to the next. RFC 2026 is not specific about
this, but I believe that its language is consistent with a
presumed general belief in the community that we should put as
few blocks in the path of advancing documents as is practical.
Put differently, it is in the community's interest to encourage
the advancement of specifications in maturity level and to
discourage changes, especially cosmetic or stylistic ones, that
might add confusion without adding value.

The one issue that _is_ specific to 2821bis (and RFC 2821
itself) is that DRUMS explicitly considered the question of
what to do about the RFC 821 examples.  The conclusion was to
eliminate the references to .ARPA (because they were
distracting and clearly impossible given the current role of
that domain) but otherwise to preserve Jon Postel's examples
(not just the ones that used USC or ISI domains) to the extent
possible.  DRUMS reached consensus on what became RFC 2821 and
the IESG signed off on it, presumably with knowledge of RFC
2606 which was completed well before 2821 was published.  So
this DISCUSS within the IESG now effectively overrides, not
only discussions and conclusions on the mailing list that
reviewed 2821bis and the consensus decision that 2821bis should
contain only those changes needed to correct error or add
clarity, but the presumably-informed discussions of the
original WG. 

The question of whether to pursue an appeal on the DISCUSS, and
the general practices of which it is an example, was raised on
the SMTP mailing list.  The consensus among most of those who
commented was that an appeal was appropriate; this appeal is
being filed on that basis.

IETF mailing list