Internet DRAFT - draft-iesg-info-exp

draft-iesg-info-exp






Network Working Group                                 B. Carpenter (ed.)
Internet-Draft                                                      IESG
Expires: December 8, 2005                                   June 6, 2005


         Choosing between Informational and Experimental Status
                       draft-iesg-info-exp-01.txt

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-
   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://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 8, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document reproduces the rules for classifying documents as
   Informational and Experimental from RFC 2026, and amplifies those
   rules with guidelines relevant to ongoing IESG evaluations.  It is
   not intended to change any of the underlying principles.








Carpenter (ed.)         Expires December 8, 2005                [Page 1]

Internet-Draft              info-experimental                  June 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

   2.   The Rules  . . . . . . . . . . . . . . . . . . . . . . . . . . 3

   3.   Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 4

   4.   Security considerations  . . . . . . . . . . . . . . . . . . . 5

   5.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5

        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5

        Intellectual Property and Copyright Statements . . . . . . . . 6




































Carpenter (ed.)         Expires December 8, 2005                [Page 2]

Internet-Draft              info-experimental                  June 2005


1.  Introduction

   In addition to standards-track documents (proposed, draft, standard
   and BCP), the RFC series contains three other categories:
   Informational, Experimental and Historic.

   People, including the IESG, are often confused about whether a given
   document should be Informational or Experimental; this document tries
   to make that determination simpler.  While this serves as commentary
   on the IETF process rules, it is not intended to change any of the
   underlying principles.  The IESG would welcome comments on this
   document, which is expected to end up as an informational web page
   (and therefore doesn't contain all the required sections for RFCs).

2.  The Rules

   The following sections are reproduced from RFC 2026, including the
   original section numbers.

   4.2 Non-Standards Track Maturity Levels

   Not every specification is on the standards track.  A specification
   may not be intended to be an Internet Standard, or it may be intended
   for eventual standardization but not yet ready to enter the standards
   track.  A specification may have been superseded by a more recent
   Internet Standard, or have otherwise fallen into disuse or disfavor.

   Specifications that are not on the standards track are labeled with
   one of three "off-track" maturity levels: "Experimental",
   "Informational", or "Historic".  The documents bearing these labels
   are not Internet Standards in any sense.

   4.2.1 Experimental

   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual contribution.

   4.2.2 Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an



Carpenter (ed.)         Expires December 8, 2005                [Page 3]

Internet-Draft              info-experimental                  June 2005


   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.

3.  Guidelines

   The rules above are not always precise.  In particular, the reasons
   for declaring something "part of a research and development effort"
   aren't clear, and the word "typically" allows a lot of wiggle room.

   So more guidelines are often needed in order to interpret the rules.

   The following set of guidelines will be used by the IESG.  The list
   is read from top to bottom; the first one that seems to apply is
   probably the one that makes sense to follow.
   1.  If it can't be practiced, it's Informational.  Unless it's a
       protocol, a procedure or a format, it is hard to see what kind of
       experiment it can be.  Case in point: "Terminology for ATM ABR
       benchmarking" (RFC 3134).
   2.  If it's not going to be changed no matter what the result is,
       it's Informational.  This is typically the case with vendor
       protocols; the vendor will publish it for the good of the
       community, but retains full change control, and gives no promises
       about listening to community feedback.  Case in point: "Microsoft
       Point-To-Point Encryption (MPPE) Protocol" (RFC 3078).
   3.  A similar case is work that could be practiced, was developed in
       the IETF, has been dropped for some reason, but is being
       published for the record.  That's Informational, unless the IESG
       determines that Historic status is more appropriate.  Case in
       point: "A Delay Bound alternative revision of RFC 2598" (RFC
       3248).
   4.  If the IETF may publish something based on this on the standards
       track once we know how well this one works, it's Experimental.
       This is the typical case of not being able to decide which
       protocol is "better" before we have experience of dealing with
       them from a stable specification.  Case in point: "PGM Reliable
       Transport Protocol Specification" (RFC 3208)





Carpenter (ed.)         Expires December 8, 2005                [Page 4]

Internet-Draft              info-experimental                  June 2005


   5.  If the document contains implicit or explicit success/failure
       criteria, and it's clear that the outcome can be used as the
       basis for a recommendation to the IETF community, it's
       Experimental.  Case in point: RFC 1797 "Class A Subnet
       Experiment" which led to RFC 1879 "Class A Subnet Experiment
       Results and Recommendations"

   Note that guideline 4 above is not intended to say that by publishing
   this, the IETF is promising to do a followup; the IETF may later
   decide that the experiment failed, and may sometimes believe this
   outcome to be very probable even when publishing the document.

   Guideline 2 may sometimes be hard to evaluate, because it requires
   evaluating the intent of the proposer; still, often it is very easy,
   and nothing further needs to be said.

4.  Security considerations

   The IESG believes that the security of the Internet is not directly
   affected by the difference between Experimental and Informational
   RFCs.

5.  Acknowledgements

   This document was originally drafted by Harald Alvestrand.  An XML
   source was created by Bill Fenner.  Useful comments were received
   from Scott Bradner, Fred Baker and others.

   This document was produced using the xml2rfc tool (RFC2629).


Author's Address

   Brian Carpenter (ed.)
   IESG

   Email: iesg@ietf.org














Carpenter (ed.)         Expires December 8, 2005                [Page 5]

Internet-Draft              info-experimental                  June 2005


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


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

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




Carpenter (ed.)         Expires December 8, 2005                [Page 6]