John C Klensin
2008-06-14 01:14:38 UTC
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
mechanisms.
(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
publication.
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
track.
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
activities.
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.,
"example.com" 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"
[http://www.ietf.org/ietf/1id-guidelines.html], nor even the
IESG-produced "Internet Draft Checklist" ("IDNits")
[http://www.ietf.org/ID-Checklist.html] 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"
(http://www.ietf.org/ietf/1id-guidelines.html) does not mention
the issue of examples at all.
(2) The I-D Checklist (IDnits,
http://www.ietf.org/ID-Checklist.html), 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
foo.example.com 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
(http://www.ietf.org/IESG/STATEMENTS/discuss-criteria.html)
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
nonsense."
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.
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
mechanisms.
(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
publication.
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
track.
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
activities.
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.,
"example.com" 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"
[http://www.ietf.org/ietf/1id-guidelines.html], nor even the
IESG-produced "Internet Draft Checklist" ("IDNits")
[http://www.ietf.org/ID-Checklist.html] 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"
(http://www.ietf.org/ietf/1id-guidelines.html) does not mention
the issue of examples at all.
(2) The I-D Checklist (IDnits,
http://www.ietf.org/ID-Checklist.html), 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
foo.example.com 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
(http://www.ietf.org/IESG/STATEMENTS/discuss-criteria.html)
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
nonsense."
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.