[Search] [pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 rfc3933                         Best Current Practice
Network Working Group                                         J. Klensin
Internet-Draft                                                S. Dawkins
Expires: October 12, 2004                                 April 13, 2004

                  A model for IETF Process Experiments

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 12, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


   The IETF has designed process changes over the last ten years in one
   of two ways -- announcement by the IESG, sometimes based on informal
   agreements with limited community involvement, and awareness, and
   formal use of same mechanism as is used for protocol specification.
   The first mechanism has often proven to be too lightweight, the
   second too heavyweight. There is a middle ground.

   This document proposes a middle-ground approach to the system of
   making changes to IETF process, one that relies heavily on a "propose
   and carry out an experiment, evaluate the experiment, and then
   establish permanent procedures based on operational experience" model

Klensin & Dawkins       Expires October 12, 2004                [Page 1]

Internet-Draft            Process Experiments                 April 2004

   rather than the ones that have been attempted previously.

Table of Contents

   1.   Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.   Security Considerations  . . . . . . . . . . . . . . . . . . . 6
   3.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
   A.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
        Intellectual Property and Copyright Statements . . . . . . . . 9

Klensin & Dawkins       Expires October 12, 2004                [Page 2]

Internet-Draft            Process Experiments                 April 2004

1.  Proposal

   Since the 1992 changes documented in RFC 1396, the IETF has used two
   mechanisms for process changes.
   1.  IESG has adopted a number of procedural changes on its own
       initiative and documented them informally, utilizing the wide
       discretion implicitly granted them by RFC 2026. This provided a
       lightweight mechanism for change, but the lightness came with a
       cost: there was sometimes too little alignment with the larger
       IETF community.
   2.  The IETF has also used the RFC 2026 protocol standards
       development process (identify a community of interest, hold one
       or more BoFs, charter a working group, discuss proposed changes
       within the community, develop IETF-wide consensus on the changes,
       and publish (usually) Best Current Practice specifications. This
       provided full community involvement, but also came with a cost in
       flexibility. The IETF does not change its formal processes often
       (the IPR clarifications in RFCs 3667-3668 are the first
       documented changes to RFC 2026 since 1996), and the community is
       understandably reluctant to permanently alter or extend
       formally-adopted processes with untried new procedures.

   There is a middle ground between BCP process updates and informal
   agreements. This document proposes to regularize and formalize the
   mechanism listed first above as a means of moving forward with
   procedural changes that might prove valuable.

   The mechanisms outlined here are not intended to be exclusive: they
   add to the IESG's range of tools for dealing with process issues on
   an ongoing basis, rather that replacing those tools with a single
   "magic bullet".  The choice as to whether to use the procedure
   outlined in this document (if it is adopted) or other mechanisms
   available to the IESG and the community --present or future-- remains
   in the IESG's hands.  If the IESG does not exercise that discretion
   wisely, this document provides no additional remedies.

   Some have read the current procedures as giving the IESG all of the
   capabilities outlined here, i.e., this document changes almost
   nothing.   If this is true, this document only encourages the IESG to
   use this type of mechanism more frequently in preference to less
   streamlined ones,  and to more explicitly document what it is doing
   and what decisions it is making.

   We propose to permit (and encourage) the IESG to adopt and institute
   "process experiments" using the following procedure:
   1.  An I-D is written that describes what the proposed new or altered
       procedure is about and how it works. A statement of what problem
       it is expected to solve would be desirable, but is not a

Klensin & Dawkins       Expires October 12, 2004                [Page 3]

Internet-Draft            Process Experiments                 April 2004

       requirement (the intent is to keep the firm requirements for such
       an experiment as lightweight as possible).  Similarly, specific
       experimental or evaluation criteria are very desirable, but not
       required -- for some of the process changes we anticipate, having
       the IESG reach a conclusion at the end of the sunset period that
       the community generally believes things to be better (or worse)
       will be both adequate and sufficient.  The I-D must state an
       explicit "sunset" timeout, typically not to exceed one year after
   2.  If the IESG believes the proposal is plausible and plausibly
       useful, a four week IETF Last Call is initiated.   The IESG can
       institute whatever procedures it wishes to make that
       determination and to avoid denial of service attacks from large
       numbers of spurious or unimportant proposals.  In particular,
       they might institute a procedure requiring some number of
       endorsements, or endorsements of a particular type, before the
       IESG considers the draft.  The IESG is, however, expected to
       understand that procedures or review processes that act as a
       mechanism for significant delays do not fall within the intent of
       this proposal.
   3.  At the conclusion of the Last Call, the IESG reevaluates the
       plausibility and appropriateness of the proposal.  If they
       conclude that the proposed experiment is appropriate, a second
       I-D is generated (either by the IESG or by the original authors
       with IESG advice) that cleans up any definitional issues exposed
       in the Last Call and that explicitly identifies and responds to
       issues raised during that Last Call.
   4.  The document and experiment are then announced, the experiment is
       begun, and the document is forwarded for publication as an
       Experimental RFC.

   The IESG is explicitly authorized to use this mechanism (based on
   Experimental RFCs) to gain experience with proposed changes to BCP
   specifications - there is no requirement to approve a BCP
   specification for the experiment until the experiment is found to
   have value.

   The IESG could, of course, reach a "bad idea" conclusion at any stage
   in this process and abandon the experiment.  It might recommend
   publication of the experimental document, with a discussion of why it
   was a bad idea, but is not required to do so.  The list above is
   deliberately agnostic about where the I-Ds come from: a WG, design
   team, individual contribution, editing group, or other mechanism,
   could be used in the first and/or third steps, but no specific
   mechanisms are required and the IESG is explicitly permitted to
   generate such proposals internally.

   In each case, the IESG's making of the decisions to go forward (or

Klensin & Dawkins       Expires October 12, 2004                [Page 4]

Internet-Draft            Process Experiments                 April 2004

   not) with a procedural experiment, or the steps leading up to one, is
   expected to reflect their judgment of the existence of rough
   consensus in the community.  That judgment may be appealed using the
   usual procedures, but the IESG and the community are reminded that an
   experimental attempt to try something for a fixed period is typically
   a better engineering approach than extended philosophical discussion
   without any experience to back it up.

   Nothing above is to be construed as a requirement that any given
   process experiment be attempted IETF-wide.  A proposal for such an
   experiment may specify selected areas, selected working groups,
   working groups meeting some specific criteria (such as those created
   after a particular time or more than a specified number of years
   old), or be specific in other ways.

   At or before the end of the "sunset" timeout, the IESG would either
   revise (or cause to be revised) the document into a BCP RFC or the
   procedure would expire and, presumably, not be tried again unless
   something changed radically.  A document describing why the
   experiment had succeeded or failed would be desirable but could not,
   realistically, be a requirement.  If the procedure went to BCP, the
   BCP would reflect what we would call "operational experience" in the
   real world.

   We note that, if the procedures the IESG has adopted (and procedural
   exceptions it has made) over the last decade are legitimate, then the
   IESG has the authority to institute the changes proposed here by
   bootstrapping the proposed process.

Klensin & Dawkins       Expires October 12, 2004                [Page 5]

Internet-Draft            Process Experiments                 April 2004

2.  Security Considerations

   This document specifies a mechanism for evolving IETF procedures. It
   does not raise or consider any protocol-specific security issues. In
   considering experimental changes to procedures, the IESG should, of
   course, exercise due caution that such changes not reduce the quality
   of security review and consideration for protocols or, at least, that
   the process experiment proposals contain early detection and
   correction mechanisms should quality deterioration occur.

Klensin & Dawkins       Expires October 12, 2004                [Page 6]

Internet-Draft            Process Experiments                 April 2004

3.  Acknowledgements

   The first revision of this document benefited significantly from
   suggestions and comments from Avri Doria, Margaret Wasserman, and
   Harald Alvestrand, and from discussions with the General Area
   Directorate and at its open meeting during IETF 59.  After mailing
   list discussion, considerable explanatory material was removed to a
   separate document for the current version.

   The first version of this document was posted as an Internet Draft on
   7 February 2004.

Authors' Addresses

   John C Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140

   Phone: +1 617 491 5735
   EMail: john-ietf@jck.com

   Spencer Dawkins
   1547 Rivercrest Blvd.
   Allen, TX  75002

   Phone: +1 469 330 3616
   EMail: spencer@mcsr-labs.org

Klensin & Dawkins       Expires October 12, 2004                [Page 7]

Internet-Draft            Process Experiments                 April 2004

Appendix A.  References
   [RFC1396]: "The Process for Organization of Internet Standards", RFC
      1396, S. Crocker and POISED Working Group, 1993
   [RFC2026]: "The Internet Standards Process -- Revision 3", RFC 2026
      (also BCP 9), S. Bradner (editor), 1996
   [RFC3667]: "IETF Rights in Contributions", RFC 3667 (also BCP 78), S.
      Bradner (editor), 2004
   [RFC3668]: "Intellectual Property Rights in IETF Technology", RFC
      3668 (also BCP 79), S. Bradner (editor), 2004

Klensin & Dawkins       Expires October 12, 2004                [Page 8]

Internet-Draft            Process Experiments                 April 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Klensin & Dawkins       Expires October 12, 2004                [Page 9]