Network Working Group H. Alvestrand Internet-Draft Google Expires: November 13, 2006 May 12, 2006 IETF Operational Notes draft-alvestrand-ipod-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 13, 2006. 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. Comments should be sent to the author, or to the IETF list: Alvestrand Expires November 13, 2006 [Page 1] Internet-Draft ION May 2006 ietf@ietf.org. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A description of the ION mechanism . . . . . . . . . . . . . . 3 2.1. Properties of an ION . . . . . . . . . . . . . . . . . . . 3 2.2. ION approval . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Draft IONs . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. The ION Store . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposed initial IONs . . . . . . . . . . . . . . . . . . . . 5 4. Success criteria and sunset period . . . . . . . . . . . . . . 6 5. Background and motivation . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Changes from version -00 to version -01 . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Alvestrand Expires November 13, 2006 [Page 2] Internet-Draft ION May 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 veichle. 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 describe 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). 2.2. ION approval An ION is always approved by some body. This document suggests that the IESG be given supreme authority over the ION mechanism, subject Alvestrand Expires November 13, 2006 [Page 3] Internet-Draft ION May 2006 to appeal, but encourages the IESG to share the right to approve IONs with other bodies. The IESG is responsible for approving the document that gives the list of current ION approvers. An initial set of ION approvers may be the IESG, the IAB, the IAOC and the IAD. 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 previoiusly-approving body. In case of conflict, or when the previous body no longer exists. A decision by any other body than the IESG to publish 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 publish an ION cannot be appealed to the IAB. (extreme boilerplate) In the case that the IESG ceases to exist, its successors or assigns 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. 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 World Wide Web Alvestrand Expires November 13, 2006 [Page 4] Internet-Draft ION May 2006 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, but all drafts will be deleted from it when the document is approved. 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 o The list of ION approvers The following list of documents, some of which currently exist, are 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 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 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)RFC3978 [RFC3978] Alvestrand Expires November 13, 2006 [Page 5] Internet-Draft ION May 2006 o IETF Rights in Technology (currently BCP 79)RFC3979 [RFC3979] o IETF mailing list management (currently RFC3005 [RFC3005], BCP 45, RFC3683 [RFC3683], BCP 83, and RFC3934 [RFC3934], BCP 94) 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: 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 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. 5. Background and motivation This section may be deleted from the final document, if that is useful. It serves mainly as a primer for discussions about the doucment. 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. Alvestrand Expires November 13, 2006 [Page 6] Internet-Draft ION May 2006 At the present time (spring 2006), there are three kinds of documents used for IETF documentation of its operations and procedures: o BCP and Info 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 this mechanism is not available for Info documents; "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. 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 Alvestrand Expires November 13, 2006 [Page 7] Internet-Draft ION May 2006 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 standars 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 This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations IONs shouldn't have much need to talk about security. 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 (draft-klensin-std-repurposing). 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004. Alvestrand Expires November 13, 2006 [Page 8] Internet-Draft ION May 2006 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. Appendix A. Changes from version -00 to version -01 This section should be deleted before publication as an RFC. The name of the document class was changed from IPOD to ION. Alvestrand Expires November 13, 2006 [Page 9] Internet-Draft ION May 2006 Author's Address Harald Tveit Alvestrand Google Email: harald@alvestrand.no Alvestrand Expires November 13, 2006 [Page 10] Internet-Draft ION May 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Alvestrand Expires November 13, 2006 [Page 11]