A Model for IETF Process Experiments
RFC 3933

Document Type RFC - Best Current Practice (November 2004; Errata)
Also known as BCP 93
Was draft-klensin-process-july14 (individual in gen area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3933 (Best Current Practice)
Telechat date
Responsible AD Harald Alvestrand
Send notices to (None)
Network Working Group                                         J. Klensin
Request for Comments: 3933                                    S. Dawkins
BCP: 93                                                    November 2004
Category: Best Current Practice

                  A Model for IETF Process Experiments

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   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 the same mechanism used for protocol specification.
   The first mechanism has often proven to be too lightweight, the
   second too heavyweight.

   This document specifies 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
   rather than those previously attempted.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Background and Specification . . . . . . . . . . . . . . . . . 2
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 5
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
       5.1.  Normative Reference. . . . . . . . . . . . . . . . . . . 5
       5.2.  Informative References . . . . . . . . . . . . . . . . . 5
   6.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7

Klensin & Dawkins        Best Current Practice                  [Page 1]
RFC 3933          A Model for IETF Process Experiments     November 2004

1.  Introduction

   This document specifies 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
   rather than those previously attempted.

2.  Background and Specification

   Since the 1992 changes documented in [RFC1396], 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 to them by [RFC2026].  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 [RFC2026] protocol standards
      development process to 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 [RFC3667, RFC3668] are the first
      documented changes to [RFC2026] 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 specifies regularizing and formalizing the
   informal IESG mechanisms listed in 1 above as a means of moving
   forward with procedural changes that might prove valuable.

   The mechanisms outlined here add to the IESG's range of tools for
   dealing with process issues on an ongoing basis.  They supplement the
   existing tools rather than attempting to replace them with a single
   "magic bullet".  The choice of using the procedure outlined in this
   document 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 this discretion wisely, this document provides no
   additional remedies.

Klensin & Dawkins        Best Current Practice                  [Page 2]
RFC 3933          A Model for IETF Process Experiments     November 2004

   Some have interpreted the current procedures as giving the IESG all
Show full document text