Proposed mechanics for document advancement
draft-hardie-advance-mechanics-00

Abstract

The IETF has maintained a three-stage standards track for some time, with basic mechanics set out in RFC 2026 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) [RFC2026]. The mechanics as described, however, are not currently used in practice and advancement along the standards track is both unusual and more difficult than many IETF participants find reasonable. This document proposes an update to those mechanics, in the interest of improving the overall functioning of the IETF. It is compatible with, but does not require, a move to a two-stage standards track.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

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 19, 2011.

Copyright Notice

Copyright (c) 2010 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.

Table of Contents

1.  Introduction
2.  Document processing
3.  Mechanics for moving from Proposed to Draft
4.  Guidance for Objections
5.  Mechanics for moving to Full Standard
6.  Workload
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Author's Address

1.  Introduction

The IETF has maintained a three-stage standards track for some time, with basic mechanics set out in RFC 2026 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) [RFC2026]. The mechanics as described, however, are not currently used in practice and advancement along the standards track is both unusual and more difficult than many IETF participants find reasonable. This document proposes an update to those mechanics, in the interest of improving the overall functioning of the IETF by aligning advancement along the standards track with the current document processing model.

2.  Document processing

In practice, IETF document processing has evolved to a model which can be described as "objection based processing". A document put forward by an author team advances from the relevant working group to IETF consideration after all objections from within the working group have been considered. The IETF Last Call is, in practice, a way for the larger community to object to a document or elements within it. IESG document processing is, fundamentally, a process by which a sponsor resolves any objections raised by other area directors; though the term used is "discuss" and some delegation occurs (to document shepherds or review teams), the basic model is clear.

This document proposes using this model for the advancement of documents along the standards track. Rather than requiring specific actions to advance, it proposes instead to test for objections to advancement at specific intervals. Documents for which no objections to advancement are present or for which the objections can be met advance. Those that have objections that cannot be met must be revised and re-issued at the baseline level before they can advance.

While this might seem to run the risk of advancing documents too early, in practice the current methods for assessing Proposed standards are sufficiently stringent that they match earlier Draft reasonably well. It is also relatively clear that the energy to object can always be found in the IETF, even when the energy to sponsor or shepherd a document is absent. By using objection based processing with auto advancement, we move with, rather than against, the methods currently at the heart of IETF mechanics.

3.  Mechanics for moving from Proposed to Draft

All documents which are published as Proposed Standard RFCs shall be entered in queue for advancement to Draft Standard, with automatic advancement to take place two years from the issue date of the RFC. A "Last Call for Objections to Advancement" must be issued 4 weeks prior to advancement. If no objections are received, the document advances.

If objections are received, the IESG issues a call for a document shepherd willing to work for resolution of the objections and advancement. If no document shepherd comes forward, the objections are automatically sustained and the document remains at Proposed Standard. If more than one volunteer steps forward, the relevant area directors select from among them. An Area Director may serve as shepherd for advancement, but there is no requirement that the AD do so. If a document shepherd is available, he or she works to resolve the objections.

If the objections are withdrawn, the document gets a new "Last Call" and then moves forward as above. If they are not withdrawn, the document shepherd may request consideration by the IESG of whether the objections merit holding the document at Proposed. If the IESG sustains the objections, the document remains at Proposed. If the IESG is in favor of advancement, the document advances. This is subject to appeal per the usual process.

If a new document must be prepared to meet the objections, it must recycle at Proposed Standard and the clock for automatic advancement starts again.

4.  Guidance for Objections

Those who are entering errata for a published RFC should indicate whether they believe the issue raised is sufficient to block advancement. The collected errata which have been so flagged are considered as objections at the Last Call period. Auto-posting of these as a response to the "Last Call" for Objections to Advancement might be worthwhile, in order to indicate the issues already raised to others considering objections

Objections based on ongoing work to prepare a replacement document should generally be upheld, especially when that work is taking place within an IETF working group, but they are not automatic

Objections must be sent to the IETF main list in response to the last call if they are not listed errata. Any individual who has been banned from the IETF main list may not post an objection, and repeated frivolous objections should be considered grounds for removal of posting rights.

5.  Mechanics for moving to Full Standard

The mechanics for moving to Full are the same as those for moving to Draft, except that the clock runs for five years from the initial publication as Proposed Standard.

6.  Workload

The current system is effectively a single-stage standards process for almost all documents. Any proposal to restore a multi-stage standards process adds to the workload of those involved in the document processing. This proposal attempt to manage that workload by allowing documents with no objections to pass without further effort. It also attempts to spread the load of managing objections to the community, by using document shepherds from outside the IESG in the common case. If no document shepherd from the community is available, documents do stall, but this is a feature, not a bug. If there are objections to advancement and no one willing to counter them or work through them, community disinterest should be taken as upholding the objection.

It would be possible to combine this procedure with a reduction in the number of standards levels. This would further reduce the workload if the advancement from stage two to stage three attracts significant objections.

7.  IANA Considerations

This document makes no request of IANA.

8.  Security Considerations

This document has no direct implications for protocol security. If the broader Internet community is judging protocol maturity based on standards level, there is some risk that changing the mechanism by which documents advance along the standards track may require that judgement to change.

9.  Acknowledgements

Jon Peterson, Russ Housley, and April Marine were kind enough to read a draft of this document. Their good nature should not be taken as supporting this proposal however, and all errors are the responsibility of the author.

10.  References

10.1. Normative References

10.2. Informative References

Author's Address