IETF Operational Notes
RFC 4693
Document | Type |
RFC - Historic
(October 2006; No errata)
Obsoleted by RFC 6393
Was draft-alvestrand-ipod (individual in gen area)
|
|
---|---|---|---|
Author | Harald Alvestrand | ||
Last updated | 2018-12-20 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4693 (Historic) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
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 areShow full document text