DISCUSS Criteria in IESG Review
Date: Jul 2007; Updated May 2014
This document describes the role of the 'DISCUSS' position in the IESG review process. It gives some guidance on when a DISCUSS should and should not be issued. It also discusses procedures for DISCUSS resolution.
Table of Contents
The Internet Engineering Steering Group (IESG) is responsible for the final review of IETF documents. Members of the IESG have the option, when they review a document, of stating a 'DISCUSS' position. The DISCUSS identifies one or more issues that must be discussed in relation to the document before the document can become an RFC. As such, 'DISCUSS' is a blocking position; the document cannot proceed until any issues are resolved to the satisfaction of the Area Director who issued the DISCUSS. For cases where the reasoning for an unresolved DISCUSS does not reflect the consensus of the IESG, override procedures can be invoked to unblock documents.
The criteria set forward in this document are intended to serve two purposes: to educate and to improve consistency. When new members join the IESG, it might not be immediately clear when it is appropriate to issue a DISCUSS and when a non-blocking comment should be preferred. Even among the standing IESG (at the time this document was written), it is clear that different Area Directors use different criteria for issuing a DISCUSS. While this is not innately problematic, greater consistency in evaluating the severity of an issue would reduce unnecessary document delays and blockages.
This document approaches IESG review of Proposed Standard documents as a review of "last resort". Most such documents reviewed by the IESG are produced and reviewed in the context of IETF working groups. In those cases, the IESG cannot overrule working group consensus without good reason; informed community consensus should prevail.
While this document serves as commentary on the way the IESG applies the IETF process rules, it is not intended to change any of the underlying principles, including RFC2026 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) . These criteria are not intended to constrain the IESG from issuing DISCUSSes on documents that are genuinely problematic, but rather to set reasonable expectation among the IESG and the community about the propriety of and justification for blocking IETF documents. The IESG would welcome comments on this document, which is expected to end up as an informational web page. Comments can be sent to firstname.lastname@example.org.
2. Document Classes Reviewed by the IESG
The IESG reviews several classes of document, and applies different criteria to each of these document types. The exemplary questions that follow appear on each IESG agenda to remind the Area Directors of the appropriate level of review for these classes:
Of these document classes, the fundamental distinction between "Protocol Actions" and "Document Actions" involves the relation of these documents to the IETF Standards Track. Only Standards Track and Best Common Practice documents are considered for "Protocol Action"; Informational and Experimental documents are considered for "Document Action".
Protocol Actions are naturally subject to greater scrutiny than Document Actions; Area Directors are not even required to state a position on a Document Action (the default being "No Objection"). Accordingly, the exact criteria used to evaluate Protocol Actions would benefit from greater scrutiny. The remainder of this document focuses on the use of DISCUSS for standards-track and BCP documents.
3. Protocol Action Criteria
3.1. DISCUSS Criteria
The following are legitimate reasons that an Area Director might state a DISCUSS position on a Protocol Action. This cannot be an exhaustive list, but this set should be taken as exemplary of the common causes for DISCUSSes seen by the IESG in the past.
3.2. DISCUSS Non-Criteria
None of the following are criteria for which the IESG should DISCUSS a document; though they might reasonably form the basis of a non-blocking comment on a document.
3.3. Saying No to A Document
In some cases an AD may believe that a document has fundamental flaws that cannot be fixed. Normally in such cases the AD will write up a description of these flaws and enter an "Abstain" position on the ballot. Such a position does not support publication of the document but also does not block the rest of the IESG from approving the document. Normally, entering an Abstain position is a sufficient mechanism for an AD to voice his or her objections.
However, there may be cases where an AD believes that the mechanisms described in a document may cause significant damage to the Internet and/or that the mechanisms described in a document are sufficiently incompatible with the Internet architecture that a document must not be published, despite the fact that the document is within scope for the WG and represents WG consensus. This situation should be extremely rare, and an AD should not take this position lightly, but this does represent an important cross-area "back-stop" function of the IESG.
In this situation, the AD will enter a "DISCUSS" position on the ballot and explain his or her position as clearly as possible in the tracker. The AD should also be willing to explain his or her position to the other ADs and to the WG.
It is possible in such a situation that the WG will understand the AD's objections and choose to withdraw the document, perhaps to consider alternatives, and the situation will be resolved.
Another possibility is that the WG will disagree with the AD, and will continue to request publication of the document. In those cases the responsible AD should work with both the WG and the AD holding the DISCUSS to see of a mutually agreeable path can be found.
4. DISCUSS Resolution
The traditional method of DISCUSS resolution is the initiation of a discussion about the issues in question. This discussion may include only the IESG, particularly if the DISCUSS is resolved quickly during or following the IESG agenda when the document is presented. Usually the discussion extends to document editors and working group chairs, and entire working groups, as necessary. Increasingly, one of the working group chairs may coordinate the resolution of the DISCUSS (see  (Falk, A., Levkowetz, H., and D. Meyer, “The PROTO Process: Working Group Chair Document Shepherding,” March 2005.)).
As the conclusion of this discussion, revisions to the document may or may not be required. If revisions are required, it is customary for the Area Director to clear their DISCUSS only when the revision containing the necessary emendations has been published in the Internet-Drafts repository.
While in many cases, DISCUSSes are resolved expeditiously, there are common cases where a DISCUSS can take weeks or months to resolve, given that revisions are frequently required, and such revisions need to be checked by the AD that issued the DISCUSS. Accordingly, DISCUSSes should be used sparingly.
If a DISCUSS cannot be resolved by the working group, and the AD continues to hold his or her DISCUSS, the IESG has an alternative balloting procedure that can be used to override a single discuss position. In the alternative procedure, all ADs are required to enter a "yes" or "no" position on the document. A document will be published if two-thirds of the IESG state a position of "yes", and no more than two ADs state a "no" position. Two-thirds of the IESG is formally defined as two-thirds of the sitting ADs (current 9), except for those who are recused from voting on the document in question, rounded up to the next whole number. If three or more ADs hold a "no" position on a document using the alternative balloting procedure, or if a document fails to gather the required number of "yes" positions, the document will be returned to the WG with a "no" answer, which is one of the options described in RFC 2026.
When an AD is replaced for any reason, the successor should promptly evaluate DISCUSS ballots left by his or her predecessor, and either re-assert them, if they still meet the criteria of Section 3.1, or register "No Objection" if they do not. The successor AD is responsible for handling such DISCUSS ballots just as if they were his or her own.
The criteria provided in this document are intended to help the IESG to restrict the usage of a DISCUSS to cases where it is necessary.
5. IANA Considerations
This document contains no considerations for the IANA.
6. Security Considerations
This is a procedural document without security implications. However, the ability of the IESG to review the security properties of the submitted protocol specifications, point out and help resolve security flaws in them is vital for Internet security.
Allison Mankin and Margaret Wasserman contributed significantly to the first version of this document. Virtually all standing IESG members from 2004-2007 provided useful feedback.
8. Informative References
NOTE: This statement was edited by the IESG in May 2014. The list of IESG members during that time period may be found at http://www.ietf.org/iesg/past-members.html.