Network Working Group J. Arkko Internet-Draft Ericsson Intended status: Informational August 30, 2011 Expires: March 2, 2012 DISCUSS Criteria on IESG Review of Internet Standard Documents draft-iesg-discuss-criteria-advancing-00 Abstract The existing IESG statement on what types of DISCUSSes are appropriate focuses mainly on new RFCs. This IESG statement provides guidelines for appropriate discusses in documents that are advancing on the Standards Track, i.e., moving to Internet Standard status. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 2, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Arkko Expires March 2, 2012 [Page 1] Internet-Draft DISCUSS Criteria Update August 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DISCUSS Criteria . . . . . . . . . . . . . . . . . . . . . . . 4 3. DISCUSS Non-Criteria . . . . . . . . . . . . . . . . . . . . . 6 4. DISCUSS Resolution . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Arkko Expires March 2, 2012 [Page 2] Internet-Draft DISCUSS Criteria Update August 2011 1. Introduction 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 [IESG.Wiki]. 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 all issues are resolved to the satisfaction of the Area Director who issued the DISCUSS or an override procedure is invoked. The existing IESG statement on what types of DISCUSSes are appropriate focuses mainly on new RFCs [IESG.Statement]. This new IESG statement provides guidelines for appropriate discusses in documents that are advancing on the Standards Track, i.e., moving to Internet Standard status. The need for this statement was prompted by the redefinition of the advancement rules and standards levels [I-D.housley-two-maturity-levels]. The goals of the redefinition are to reflect existing practice and to make it easier to advance documents as deployment experience is gathered. Discussion in the community has shown that the rules regarding reviews of documents advancing on the Standards Track are not clear, and, historically, the IESG and the working groups have applied differing levels of scrutiny to these documents. Arguably in some cases the level of review has not matched what is appropriate for these cases. 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. It is also 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 statement may also provide some guidance to reviewers outside the IESG and the working groups on the expected level of changes in these types of documents. IESG reviews should be considered as a review of "last resort". Most 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. As discussed in [IESG.Statement], while this document serves as Arkko Expires March 2, 2012 [Page 3] Internet-Draft DISCUSS Criteria Update August 2011 commentary on the way the IESG applies the IETF process rules, it is not intended to change any of the underlying principles, including [RFC2026]. Comments can be sent to iesg@ietf.org. The criteria in this document applies only to advancement on the Standards Track. When an RFC changes from one track to another (such as from Experimental to Proposed Standard), fundamental changes may be required in the specification and the usual DISCUSS criteria applies [IESG.Statement]. 2. DISCUSS Criteria Documents advancing on the Standards Track have already appeared as RFCs and extensively reviewed at that time. A document can only move forward if sufficient implementation and deployment experience can be reported. As a result, there is evidence that the specification is clear enough to be implementable and interoperable, and works well enough to be deployed at least in some environments. There are no absolute rules about what changes are desirable or acceptable between the old and the new RFC. But in the above light the general guideline is that only the absolutely necessary changes should be performed. Furthermore, a document cannot advance on the Standards Track if the protocol it describes substantially changes from the previous version. Adding new features, for instance, requires reissuing the RFC as a Proposed Standard level, which is sometimes referred to as "recycling". In view of this, the IESG should limit itself far more when raising DISCUSSes for advancing documents on the Standards Track than for documents appearing for the first time. In general, it is hard to argue that a protocol with extensive implementation and deployment experience has a flaw that requires a modification before the RFC can be re-issued. Typically, technical issues serious enough to require a blocking comment should not exist, and such discusses should be reserved for exceptional circumstances. The types of DISCUSSes appropriate for documents advancing on the Standards Track include: o Process issues are a valid cause for a DISCUSS. For instance, the document may fail to satisfy advancement criteria, the proper IETF process for bringing the document forward may not have been followed, or the IETF lacks consensus for publishing the document. These process issues have been described in more detail in Section 3.1 of [IESG.Statement] and in [I-D.housley-two-maturity-levels]. Arkko Expires March 2, 2012 [Page 4] Internet-Draft DISCUSS Criteria Update August 2011 o Other process problems related to advancement are also a valid cause for a DISCUSS. For instance, substantial protocol extensions are not allowed when advancing the document to the next maturity level. o Serious technical problems that relate to new information uncovered since the publication of the previous RFC or the evolution of the Internet environment in the meantime are also a valid cause for a DISCUSS. These issues should be raised only in exceptional situations where widespread deployment would be damaging to the Internet or an enterprise network for reasons of congestion control, scalability, or the like, or if the specification is now known to have serious security vulnerabilities that must be addressed or at least described. o The focus of the IESG reviews is typically the differences between the original RFC and the proposed new one. Issues within the new text are subject to the usual new document review scrutiny and [IESG.Statement] applies. o Backwards compatibility is an important aspect of the differences. Problems may arise, for instance, when tightening up RFC 2119 [RFC2119] language in the new RFC. An issue with backwards compatibility with the previous RFC is a valid reason to raise a DISCUSS. o There may also be effects to other RFCs. For instance, removing unused functionality may affect a MIB that supports that functionality. A DISCUSS may be raised if such effects are not properly documented. Even in situations where serious technical problems can be identified, it should be considered whether some form other than updating the document should be applied. For instance, a security vulnerability could be described and mitigated in a separate document. Examples of valid reasons for a DISCUSS include failure to provide an explanation of how the criteria in [I-D.housley-two-maturity-levels] has been fulfilled, an existing errata that may affect interoperability, or an attempt to publish a new RFC without as much as a reference to a newly discovered serious security vulnerability. One approach to raising a technical issue is to suggest that a particular issue (such as a new security vulnerability) would require a change in the protocol and therefore require recycling at Proposed Standard maturity level. Arkko Expires March 2, 2012 [Page 5] Internet-Draft DISCUSS Criteria Update August 2011 As any technically oriented DISCUSSes are reserved for serious issues, raising such issues must lead to discussion in the community, and community consensus should be respected in deciding what is the appropriate action to be taken. Failure to remove options is also a valid cause to raise a DISCUSS, if there is clear evidence that a particular option is not implemented or used. 3. DISCUSS Non-Criteria The guidelines from [IESG.Statement] apply. In addition, technical issues are typically inappropriate DISCUSSes as well, except in exceptional circumstances outlined in the previous section. Editorial, stylistic, and ID-Nits related concerns can be brought up, but their use in a DISCUSS is strongly discouraged. In general, minimizing the changes to the previously published RFC is desirable over attempts to adhere to the most current stylistic or editorial guidelines. Keeping documents even editorially as similar as possible is desirable so that implementors can as easily as possible determine what actual changes were performed in the document. 4. DISCUSS Resolution The guidelines from [IESG.Statement] apply. 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. This applies not just to the initial RFCs, but often as more experience and analysis results are gained, new vulnerabilities are often uncovered in previously published RFCs. 7. References Arkko Expires March 2, 2012 [Page 6] Internet-Draft DISCUSS Criteria Update August 2011 7.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.housley-two-maturity-levels] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", draft-housley-two-maturity-levels-08 (work in progress), June 2011. [IESG.Statement] IESG, "DISCUSS Criteria in IESG Review", IESG Statement at http://www.ietf.org/iesg/statement/discuss-criteria.html, February 2006. 7.2. Informative References [IESG.Wiki] IESG, "IESG Ballot Procedures", IESG Wiki page http://www.ietf.org/iesg/voting-procedures.html, May 2009. Appendix A. Acknowledgments This note has been prepared as a result of discussions in the IETF discussion list and in the IESG. The authors would also like to thank Ari Keranen and Magnus Westerlund for reviews. Appendix B. Contributors The IESG members at the time that this statement was prepared were: Jari Arkko Russ Housley Pete Resnick Peter Saint-Andre Ralph Droms Arkko Expires March 2, 2012 [Page 7] Internet-Draft DISCUSS Criteria Update August 2011 Ronald Bonica Dan Romascanu Gonzalo Camarillo Robert Sparks Stewart Bryant Adrian Farrel Stephen Farrell Sean Turner Wesley Eddy David Harrington Author's Address Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@ericsson.com Arkko Expires March 2, 2012 [Page 8]