Movatterモバイル変換

Network Working Group                                      H. AlvestrandRequest for Comments: 4693                                        GoogleCategory: Experimental                                      October 2006IETF Operational NotesStatus 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 anRFC 3933 process   experiment.Table of Contents1. Introduction ....................................................22. A Description of the ION Mechanism ..............................22.1. Properties of an ION .......................................22.2. ION Approval ...............................................32.3. Draft IONs .................................................32.4. The ION Store ..............................................43. Proposed Initial IONs ...........................................44. Success Criteria and Sunset Period ..............................55. Background and Motivation .......................................66. IANA Considerations .............................................77. Security Considerations .........................................88. Acknowledgements ................................................89. References ......................................................89.1. Normative References .......................................89.2. Informative References .....................................8Alvestrand                    Experimental                      [Page 1]

RFC 4693                          ION                       October 20061.  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 toRFC 3933   [RFC3933].2.  A Description of the ION Mechanism2.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 procedureAlvestrand                    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 (currentlyBCP 78)RFC 3978 [RFC3978]   o  IETF Rights in Technology (currentlyBCP 79)RFC 3979 [RFC3979]   o  IETF mailing list management (currentlyRFC 3005 [RFC3005],BCP45,RFC 3683 [RFC3683],BCP 83, andRFC 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 continueAlvestrand                    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 documentationAlvestrand                    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 20067.  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.  References9.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 toRFC 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 2006Author's Address   Harald Tveit Alvestrand   Google   Beddingen 10   N-7014 Trondheim   Norway   EMail: harald@alvestrand.noAlvestrand                    Experimental                      [Page 9]

RFC 4693                          ION                       October 2006Full Copyright Statement   Copyright (C) The Internet Society (2006).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]