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. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf