|
Network Working Group Request for Comments: 4693 Category: Experimental |
H. Alvestrand October 2006 |
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 © The Internet Society (2006).
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.
1. Introduction
2. A Description of the ION Mechanism
2.1. Properties of an ION
2.2. ION Approval
2.3. Draft IONs
2.4. The ION Store
3. Proposed Initial IONs
4. Success Criteria and Sunset Period
5. Background and Motivation
6. IANA Considerations
7. Security Considerations
8. Acknowledgements
9. References
9.1. Normative References
9.2. Informative References
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].
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:
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).
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.
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.
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.
Draft IONs shall have, instead of an approval date and an identification of the body that approved it, information about:
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.
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:
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.
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:
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.
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):
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.
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:
in the "IESG Guide" wiki has partially clarified this situation but has no official status.
This note introduces a new series that seems to fulfil the requirements for "something in between":
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.
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.
IONs will not include protocol specifications, so shouldn't have much need to talk about security the way RFCs do.
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.
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004.
[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.
Harald Tveit Alvestrand
Google
Beddingen 10
N-7014 Trondheim
Norway
EMail: harald@alvestrand.no
Copyright © 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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).