doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc4693.txt b/doc/rfc/rfc4693.txt
new file mode 100644
index 0000000..0b019cd
--- /dev/null
+++ b/doc/rfc/rfc4693.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                      H. Alvestrand
+Request for Comments: 4693                                        Google
+Category: Experimental                                      October 2006
+
+
+                         IETF Operational Notes
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a new document series intended for use as a
+   repository for IETF 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 page.
+
+   It proposes to establish this series as an RFC 3933 process
+   experiment.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. A Description of the ION Mechanism ..............................2
+      2.1. Properties of an ION .......................................2
+      2.2. ION Approval ...............................................3
+      2.3. Draft IONs .................................................3
+      2.4. The ION Store ..............................................4
+   3. Proposed Initial IONs ...........................................4
+   4. Success Criteria and Sunset Period ..............................5
+   5. Background and Motivation .......................................6
+   6. IANA Considerations .............................................7
+   7. Security Considerations .........................................8
+   8. Acknowledgements ................................................8
+   9. References ......................................................8
+      9.1. Normative References .......................................8
+      9.2. Informative References .....................................8
+
+
+
+
+
+
+Alvestrand                    Experimental                      [Page 1]
+
+RFC 4693                          ION                       October 2006
+
+
+1.  Introduction
+
+   This document describes a new document series, called the IETF
+   Operational Notes, or IONs.
+
+   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 vehicle.
+
+   The document series defined here does not modify the IETF process
+   rules that are defined in currently valid BCP documents.
+
+   The document series is a process experiment according to RFC 3933
+   [RFC3933].
+
+2.  A Description of the ION Mechanism
+
+2.1.  Properties of an ION
+
+   An ION is a document with a certain set of attributes ("front page
+   matter").  This specification does not place any limits on what else
+   an ION can contain.
+
+   An ION 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 ION that describes expectations for ION
+   formats.
+
+   An ION is a versioned document.  When a new ION is issued with the
+   same name, it obsoletes the previous version.  When one desires to
+   retire an ION, one issues an ION saying "This document name is now
+   obsolete".
+
+   The ION name + the approval date forms a stable identifier for one
+   particular version of an ION; once it is published, it shall never be
+   changed, although it may be withdrawn (see below).
+
+
+
+
+
+
+Alvestrand                    Experimental                      [Page 2]
+
+RFC 4693                          ION                       October 2006
+
+
+   The properties list does not include a "category"; while the set of
+   documents that might be IONs is extremely wide, we do not know yet
+   which categories could make sense.  The question of categories might
+   get revisited at the end of the experiment period.
+
+   Procedurally, an ION has the formal authority of a statement from its
+   approving body.  This means that an ION cannot change those
+   procedures of the IETF that are documented via the BCP series, since
+   the BCP series represents a determination of IETF consensus.
+
+2.2.  ION Approval
+
+   An ION is always approved by some body.  The IESG is granted
+   authority by this document over the practical management of the
+   series and the definition of detailed processes and rules associated
+   with it.
+
+   The IESG, the IAB, and IAOC are given the right to approve IONs by
+   this document.  The IESG, IAB, or IAOC may decide that other groups
+   or roles should be given the right to approve IONs.
+
+   The ION-approving groups are expected to issue IONs related to their
+   own areas of responsibility, and to use common sense when IONs are
+   needed where it isn't obvious who's responsible for them.
+
+   An updated ION will normally be approved by the same body that
+   approved the previous version, or by another body with the approval
+   of the previously-approving body.  In case of conflict, or when the
+   previous body no longer exists, the IESG will decide who gets to
+   approve an updated ION.
+
+   A decision by any other body than the IESG to approve an ION 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 approve an ION cannot be appealed to the IAB.
+
+   In the case that the IESG ceases to exist, its successors or
+   assignees will take over the tasks given to the IESG in this
+   document.
+
+2.3.  Draft IONs
+
+   There is no requirement that an ION 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 IONs.
+
+
+
+
+Alvestrand                    Experimental                      [Page 3]
+
+RFC 4693                          ION                       October 2006
+
+
+   Draft IONs 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
+      any)
+
+   o  The body that is intended to approve this version
+
+   o  The appropriate forum for discussion of this draft (if any)
+
+2.4.  The ION Store
+
+   All approved IONs 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 HTTP and FTP,
+   and should offer both easy access to the "current" version of all
+   IONs and bulk download of all IONs, all versions.
+
+   This document does not constrain the form of the ION Store, but
+   mandates that there be a public one.
+
+   Public draft IONs are published separately from the approved IONs.
+   Old versions may be published in the draft store and must be kept in
+   a version management system for the duration of the experiment.
+   Experience will show what the best policy for draft retention is if
+   the series is made permanent.
+
+3.  Proposed Initial IONs
+
+   The following IONs should be created as soon as possible after this
+   document is published, to give the details of the maintenance of the
+   ION series, in order to bootstrap the process:
+
+   o  The ION Format Guide
+
+   o  The ION Store Description
+
+   The following list of documents, some of which currently exist,
+   provides examples of documents that could be converted to IONs.  This
+   is not a binding recommendation, but gives examples of what IONs can
+   be good for.
+
+   o  The I-D publishing procedure
+
+
+
+
+Alvestrand                    Experimental                      [Page 4]
+
+RFC 4693                          ION                       October 2006
+
+
+   o  The checklist for I-D submission to the IESG (formerly known as
+      id-nits)
+
+   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
+
+   Once the ION series is permanent, the existence of the ION series may
+   cause the following documents to be split into a "policy and
+   principles" BCP and a "procedures and boilerplate" document published
+   as ION:
+
+   o  IETF Rights in Documents (currently BCP 78) RFC 3978 [RFC3978]
+
+   o  IETF Rights in Technology (currently BCP 79) RFC 3979 [RFC3979]
+
+   o  IETF mailing list management (currently RFC 3005 [RFC3005], BCP
+      45, RFC 3683 [RFC3683], BCP 83, and RFC 3934 [RFC3934], BCP 94)
+
+   If someone wishes to do such a split while the experiment is running,
+   the BCPs cannot refer to the "procedures" documents as IONs, since
+   the concept of an ION may go away.  In that case, any procedures
+   removed from a BCP must either be reinstated or otherwise stored as a
+   permanently available reference.
+
+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 ION 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 (or a suitable
+   reformulation thereof):
+
+   1.  This document series has proved useful, and should be made
+       permanent
+
+   2.  This document series is less useful than the equivalent
+       information in RFCs and informal Web pages, and should be
+       abandoned
+
+   3.  We cannot decide yet; the experiment should continue
+
+
+
+
+
+Alvestrand                    Experimental                      [Page 5]
+
+RFC 4693                          ION                       October 2006
+
+
+   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.
+
+   If the IESG decides that the feedback warrants terminating the
+   series, the repository will be closed for new documents, and the
+   existing ION documents will be returned to having the same status as
+   any other Web page or file on the IETF servers -- this situation will
+   closely resemble the situation before the experiment started.
+
+5.  Background and Motivation
+
+   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
+   used for IETF documentation of its operations and procedures:
+
+   o  BCP and Informational 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 an updated Info RFC has a completely
+      different identifier from the RFC that it updates; "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
+      procedure.  For certain procedures, their informal documentation
+
+
+
+
+Alvestrand                    Experimental                      [Page 6]
+
+RFC 4693                          ION                       October 2006
+
+
+      in the "IESG Guide" wiki has partially clarified this situation
+      but has no official status.
+
+   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
+      documents.
+
+   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
+      newcomers).
+
+   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
+      document.
+
+   The "author" attribute has quite deliberately been omitted from the
+   required property list.  While there may be many cases where
+   identifying an author is a Good Thing, the responsibility for an
+   approved ION rests with the approving body.
+
+   Note: This proposal is NOT intended to affect the standards 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
+
+   IONs will not include protocol specifications, so IONs will make no
+   requests for IANA actions.  IANA will not need to review all IONs.
+
+   This document makes no requests of IANA either.
+
+
+
+
+Alvestrand                    Experimental                      [Page 7]
+
+RFC 4693                          ION                       October 2006
+
+
+7.  Security Considerations
+
+   IONs will not include protocol specifications, so shouldn't have much
+   need to talk about security the way RFCs do.
+
+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, and for his many valuable comments on
+   this document.
+
+   In addition, Dave Crocker, Spencer Dawkins, Jeff Hutzelman, Sam
+   Hartman, and David Black (gen-ART reviewer) provided valuable
+   comments at Last Call time.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC3933]  Klensin, J. and S. Dawkins, "A Model for IETF Process
+              Experiments", BCP 93, RFC 3933, November 2004.
+
+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                    Experimental                      [Page 8]
+
+RFC 4693                          ION                       October 2006
+
+
+Author's Address
+
+   Harald Tveit Alvestrand
+   Google
+   Beddingen 10
+   N-7014 Trondheim
+   Norway
+
+   EMail: harald@alvestrand.no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                    Experimental                      [Page 9]
+
+RFC 4693                          ION                       October 2006
+
+
+Full 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.
+
+   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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Alvestrand                    Experimental                     [Page 10]
+