Network Working Group Ted. Hardie
Internet-Draft Panasonic Wireless Research Lab
Intended status: BCP September 15, 2010
Expires: March 19, 2011
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 [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 [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.
Hardie Expires March 19, 2011 [Page 1]
Internet-Draft MDTLS September 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document processing . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanics for moving from Proposed to Draft . . . . . . . . . . 3
4. Guidance for Objections . . . . . . . . . . . . . . . . . . . . 4
5. Mechanics for moving to Full Standard . . . . . . . . . . . . . 5
6. Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Hardie Expires March 19, 2011 [Page 2]
Internet-Draft MDTLS September 2010
1. Introduction
The IETF has maintained a three-stage standards track for some time,
with basic mechanics set out in RFC 2026 [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.
Hardie Expires March 19, 2011 [Page 3]
Internet-Draft MDTLS September 2010
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.
Hardie Expires March 19, 2011 [Page 4]
Internet-Draft MDTLS September 2010
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.
Hardie Expires March 19, 2011 [Page 5]
Internet-Draft MDTLS September 2010
10. References
10.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.
10.2. Informative References
Author's Address
Ted Hardie
Panasonic Wireless Research Lab
10900 Tantau Ave.
Cupertino, California 95014
USA
Phone: +1-408-628-5864
Email: ted.ietf@gmail.com
Hardie Expires March 19, 2011 [Page 6]