[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 rfc4693                                           
Network Working Group                                      H. Alvestrand
Internet-Draft                                             Cisco Systems
Expires: August 21, 2006                               February 17, 2006

                 IETF Process and Operations Documentss

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

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

   This Internet-Draft will expire on August 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This document describes a new document series intended for use as a
   repository for IETF process and operations documents, which should be
   more ephemeral than RFCs, but more referenceable than internet-
   drafts, and with more clear handling procedures than a random Web

   It proposes to establish this series as an RFC 3933 process

Alvestrand               Expires August 21, 2006                [Page 1]

Internet-Draft              Process Documents              February 2006

   Comments should be sent to the author, or to the IETF list:

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  A description of the IPOD mechanism  . . . . . . . . . . . . .  3
     2.1.  Properties of an IPOD  . . . . . . . . . . . . . . . . . .  3
     2.2.  IPOD approval  . . . . . . . . . . . . . . . . . . . . . .  3
     2.3.  Draft IPODs  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.4.  The IPOD Store . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Proposed initial IPODs . . . . . . . . . . . . . . . . . . . .  5
   4.  Success criteria and sunset period . . . . . . . . . . . . . .  6
   5.  Background and motivation  . . . . . . . . . . . . . . . . . .  6
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

Alvestrand               Expires August 21, 2006                [Page 2]

Internet-Draft              Process Documents              February 2006

1.  Introduction

   This document describes a new document series, called the IETF
   Process and Operations Documents, or IPODs.

   This document series is intended to capture the set of procedures
   that the IETF follows, but for which the RFC process is an
   inappropriate documentation veichle.

   The document series is a process experiment according to RFC 3933

2.  A description of the IPOD mechanism

2.1.  Properties of an IPOD

   An IPOD is a document with a certain set of attributes ("front page
   matter").  This specification does not place any limits on what else
   an IPOD can contain.

   An IPOD has the following attributes:

   o  A name, which is usable as the filename of the document

   o  A title

   o  A date of approval

   o  An identification of the body that approved this version

   The format of the document is not restricted by this document.  It's
   suggested that there be an IPOD that describe expectations for IPODs.

   An IPOD is a versioned document.  When a new IPOD is issued with the
   same name, it obsoletes the previous version.  When one desires to
   retire an IPOD, one issues an IPOD saying "This document name is now

   The IPOD name + the approval date forms a stable identifier for one
   particular version of an IPOD; once it is published, it shall never
   be changed, although it may be withdrawn (see below).

2.2.  IPOD approval

   An IPOD is always approved by some body.  This document suggests that
   the IESG be given supreme authority over the IPOD mechanism, subject
   to appeal, but encourages the IESG to share the right to approve

Alvestrand               Expires August 21, 2006                [Page 3]

Internet-Draft              Process Documents              February 2006

   IPODs with other bodies.

   The IESG is responsible for approving the document that gives the
   list of current IPOD approvers.  An initial set of IPOD approvers may
   be the IESG, the IAB, the IAOC and the IAD.

   An updated IPOD will normally be approved by the same body that
   approved the previous version, or by another body with the approval
   of the previoiusly-approving body.  In case of conflict, or when the
   previous body no longer exists.

   A decision by any other body than the IESG to publish an IPOD can be
   appealed to the IESG, in which case the IESG can nullify the
   approval.  A decision of the IESG can be appealed using the common
   IETF appeals procedure, except that an IESG decision to nullify an
   IAB decision to publish an IPOD cannot be appealed to the IAB.

   (extreme boilerplate) In the case that the IESG ceases to exist, its
   successors or assigns will take over the tasks given to the IESG in
   this document.

2.3.  Draft IPODs

   There is no requirement that an IPOD will be published as a draft
   before publication.  This will, however, be desirable in many cases,
   and thus, this document describes the properties and procedures for
   handling draft IPODs.

   Draft IPODs shall have, instead of an approval date and an
   identification of the body that approved it, information about:

   o  The word "DRAFT", prominently displayed

   o  The publication date and time

   o  The approval date of the document it is intended to update (if

   o  The body that is intended to approve this version

   o  The appropriate forum for discussion of this draft (if any)

2.4.  The IPOD Store

   All approved IPODs are archived, in all their versions, and made
   publicly available from resources operated by the IETF secretariat.
   The store should be reachable by common methods like World Wide Web
   and FTP, and should offer both easy access to the "current" version

Alvestrand               Expires August 21, 2006                [Page 4]

Internet-Draft              Process Documents              February 2006

   of all IPODs and bulk download of all IPODs, all versions.

   This document does not constrain the form of the IPOD Store, but
   mandates that there be a public one.

   Public draft IPODs are published separately from the approved IPODs.
   Old versions MAY be published in the draft store, but all drafts will
   be deleted from it when the document is approved.

3.  Proposed initial IPODs

   The following IPODs should be created as soon as possible after this
   document is published, to give the details of the maintenance of the
   IPOD series, in order to bootstrap the process:

   o  The IPOD Format Guide

   o  The IPOD Store Description

   o  The list of IPOD approvers

   The following list of documents, some of which currently exist, are
   examples of documents that could be converted to IPODs.  This is not
   a binding recommendation, but gives examples of what IPODs can be
   good for.

   o  The I-D publishing procedure

   o  The checklist for I-D submission to the IESG (formerly known as

   o  Procedures for spam control on IETF mailing lists

   o  Procedures for requesting a WG meeting slot

   o  Procedures for IETF minutes

   o  Procedures for IESG meeting minutes

   The existence of the IPOD series may cause the following documents to
   be split into a "policy and principles" BCP and a "procedures and
   boilerplate" document published as IPOD:

   o  IETF Rights in Documents (currently BCP 78)RFC3978 [RFC3978]

   o  IETF Rights in Technology (currently BCP 79)RFC3979 [RFC3979]

Alvestrand               Expires August 21, 2006                [Page 5]

Internet-Draft              Process Documents              February 2006

   o  IETF mailing list management (currently RFC3005 [RFC3005], BCP 45,
      RFC3683 [RFC3683], BCP 83, and RFC3934 [RFC3934], BCP 94)

4.  Success criteria and sunset period

   This experiment is expected to run for a period of 12 months,
   starting from the date of the first IPOD published using this
   mechanism.  At the end of the period, the IESG should issue a call
   for comments from the community, asking for people to state their
   agreement to one of the following statements:

   1.  This document series has proved useful, and should be made

   2.  This document series is less useful than the equivalent
       information in RFCs and informal Web pages, and should be

   3.  We cannot decide yet; the experiment should continue

   The author believes that establishing objective metrics for the
   success or failure of this experiment is not a worthwhile exercise;
   the success or failure will be readily apparent in the community's
   attitudes towards the series.

   If the feedback reveals a community consensus for keeping the series,
   the IESG may choose to create a new BCP RFC containing the
   information herein, suitably modified by experience.

5.  Background and motivation

   This section may be deleted from the final document, if that is
   useful.  It serves mainly as a primer for discussions about the

   The IETF is an open organization, which means (among other things)
   that there are always newcomers coming in to learn how to perform
   work; this places a requirement on the organization to document its
   processes and procedures in an accessible manner.

   The IETF is also a large organization, which means that when
   procedures change, there are a number of people who will like to know
   of the change, to figure out what has changed, and possibly to
   protest or appeal the change if they disagree with it.

   At the present time (spring 2006), there are three kinds of documents

Alvestrand               Expires August 21, 2006                [Page 6]

Internet-Draft              Process Documents              February 2006

   used for IETF documentation of its operations and procedures:

   o  BCP and Info RFCs, which require an IETF consensus call for BCP,
      approval by the IESG, and usually a great deal of debate and
      effort to change, and which bind up editing resources in the final
      edit stage, as well as being limited (in practice) to ASCII.  The
      BCP number forms a means of having a stable reference for new
      versions of a document, but this mechanism is not available for
      Info documents; "updates/obsoletes" links can give some of the
      same information, but can also be quite confusing to follow.

   o  Web pages, which can be changed without notice, provide very
      little ability to track changes, and have no formal standing -
      confusion is often seen about who has the right to update them,
      what the process for updating them is, and so on.  It is hard when
      looking at a web page to see whether this is a current procedure,
      a procedure introduced and abandoned, or a draft of a future

   o  "floating" internet-drafts, which are frequently updated, in a
      trackable manner, but have no approval mechanism, are limited (in
      practice) to ASCII format, and whose use as semi-permanent
      documents clutters up their use as 6-month temporary working

   This note introduces a new series that seems to fulfil the
   requirements for "something in between":

   o  Unlike RFCs, they can be produced without a post-editing stage,
      they can be in any format the controllers of the series choose
      (allowing web pages with hyperlinks, which is an advantage for

   o  Also unlike RFCs, they can be produced by any body that the IESG
      gives the right to use the mechanism; this allows certain
      procedures to be updated without having to wait for the IESG
      approval cycle.

   o  Unlike internet-drafts, they have an explicit approval step - this
      allows a reader to easily see the difference between an idea and
      an operational procedure.

   o  Unlike Web pages, there is an explicit mechanism for finding "all
      current versions", and a mechanism for tracking the history of a

   The "author" attribute has quite deliberately been omitted from the
   required property list.  While there may be many cases where

Alvestrand               Expires August 21, 2006                [Page 7]

Internet-Draft              Process Documents              February 2006

   identifying an author is a Good Thing, the responsibility for an
   approved IPOD rests with the approving body.

   Note: This proposal is NOT intended to affect the standars track in
   any way - a side effect may be to reduce the number of "process BCPs"
   emitted, but this has no direct bearing on the IETF's technical
   specifications.  It is therefore not within the scope of the NEWTRK
   working group.

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

7.  Security Considerations

   Given that IPOD is a trademark registered in the categories IC 009,
   010 016, 020, 025, 035, 039, 041 and US 001 002 005 007 019 021 022
   023 026 029 032 036 037 038 039 042 044 050 100, 101 102 105 and 107,
   a better name for the document series might be IETF Policy and
   Operations Notes.

8.  Acknowledgements

   Many people have contributed over the years to the ideas that I have
   tried to express here.

   I'm in particular indebted to John Klensin for his work on trying to
   find a balance between formalism and flexibility in the IETF process,
   and for his earlier attempts at creating such a document series as an
   adjunct to the "ISD" effort (draft-klensin-std-repurposing).

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3933]  Klensin, J. and S. Dawkins, "A Model for IETF Process
              Experiments", BCP 93, RFC 3933, November 2004.

Alvestrand               Expires August 21, 2006                [Page 8]

Internet-Draft              Process Documents              February 2006

9.2.  Informative References

   [RFC3005]  Harris, S., "IETF Discussion List Charter", BCP 45,
              RFC 3005, November 2000.

   [RFC3683]  Rose, M., "A Practice for Revoking Posting Rights to IETF
              mailing lists", BCP 83, RFC 3683, February 2004.

   [RFC3934]  Wasserman, M., "Updates to RFC 2418 Regarding the
              Management of IETF Mailing Lists", BCP 94, RFC 3934,
              October 2004.

   [RFC3978]  Bradner, S., "IETF Rights in Contributions", BCP 78,
              RFC 3978, March 2005.

   [RFC3979]  Bradner, S., "Intellectual Property Rights in IETF
              Technology", BCP 79, RFC 3979, March 2005.

Alvestrand               Expires August 21, 2006                [Page 9]

Internet-Draft              Process Documents              February 2006

Author's Address

   Harald Tveit Alvestrand
   Cisco Systems

   Email: harald@alvestrand.no

Alvestrand               Expires August 21, 2006               [Page 10]

Internet-Draft              Process Documents              February 2006

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 procedures with respect to rights in RFC 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 (2006).  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.

Alvestrand               Expires August 21, 2006               [Page 11]