GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3933

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
 of the capabilities outlined here.  If this were 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 its actions and decisions.
 This specification permits and encourages the IESG to adopt and
 institute "process experiments" by using the following procedure:
 1. An I-D is written describing the proposed new or altered
    procedure.  A statement of the problem expected to be resolved is
    desirable but not required (the intent is to keep the firm
    requirements for such an experiment as lightweight as possible).
    Similarly, specific experimental or evaluative criteria, although
    highly desirable, are 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 adoption.
 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 this determination
    and to avoid denial of service attacks from large numbers of
    spurious or unimportant proposals.  In particular, they might
    institute a procedure requiring a number of endorsements, or
    endorsements of a particular type, before the IESG considers the
    proposal.  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
    specification.
 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 the 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.

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

 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 vague 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 decision to go forward (or 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 requiring an IETF-wide attempt
 for any given process experiment.  A proposal for such an experiment
 may specify selected areas, selected working groups, working groups
 meeting some specific criteria (e.g., those created after a
 particular time or of a specified age), 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 the
 procedural exceptions it has made) over the last decade are
 legitimate, then the IESG has the authority to institute the changes
 specified here by bootstrapping this process.

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

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

4. 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
 February 7, 2004.

5. References

5.1. Normative References

 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.

5.2. Informative References

 [RFC1396] Crocker, S., "The Process for Organization of Internet
           Standards Working Group (POISED)", RFC 1396, January 1993.
 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
           3667, February 2004.
 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
           Technology", BCP 79, RFC 3668, February 2004.

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

6. Authors' Addresses

 John C Klensin
 1770 Massachusetts Ave, #322
 Cambridge, MA  02140
 USA
 Phone: +1 617 491 5735
 EMail: john-ietf@jck.com
 Spencer Dawkins
 1547 Rivercrest Blvd.
 Allen, TX  75002
 USA
 Phone: +1 469 330 3616
 EMail: spencer@mcsr-labs.org

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

Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and at www.rfc-editor.org, and except as set
 forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 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 ISOC's procedures with respect to rights in ISOC 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
 http://www.ietf.org/ipr.
 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 ietf-
 ipr@ietf.org.

Acknowledgement

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

Klensin & Dawkins Best Current Practice [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3933.txt · Last modified: 2004/11/05 00:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki