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 | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized (tools) 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 are
Show full document text