summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4693.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4693.txt')
-rw-r--r--doc/rfc/rfc4693.txt563
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]
+