summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4845.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4845.txt')
-rw-r--r--doc/rfc/rfc4845.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc4845.txt b/doc/rfc/rfc4845.txt
new file mode 100644
index 0000000..cb375fb
--- /dev/null
+++ b/doc/rfc/rfc4845.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group L. Daigle, Ed.
+Request for Comments: 4845
+Category: Informational Internet Architecture Board
+ (IAB)
+ July 2007
+
+
+ Process for Publication of IAB RFCs
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ From time to time, the Internet Architecture Board (IAB) publishes
+ documents as Requests for Comments (RFCs). This document defines the
+ process by which those documents are produced, reviewed, and
+ published in the RFC Series.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Review and Approval . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. IAB RFC Publication Process . . . . . . . . . . . . . . . . . . 3
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3
+ 5. IAB Members at the Time of Approval . . . . . . . . . . . . . . 4
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 1]
+
+RFC 4845 IAB RFC Publication Process July 2007
+
+
+1. Introduction
+
+ From time to time, the IAB has cause to publish documents as Requests
+ for Comments (RFCs). These occasions include the following:
+
+ o documents that arise from consideration of an issue by the IAB and
+ are authored by the IAB through a nominated editor.
+
+ o documents that report on IAB activities, such as workshop reports,
+ and are authored by a nominated editor, generally from among the
+ activity participants.
+
+ o documents that are not the outcome of an Internet Engineering Task
+ Force (IETF) Working Group effort but that the IAB has determined
+ would be of benefit to the IETF community to publish. Such
+ documents need not necessarily be authored or revised by the IAB.
+
+ The majority of documents published by the IAB will be classified as
+ Informational RFCs (see [RFC2026]). Generally speaking, the IAB does
+ not publish Standards-Track or Experimental RFCs. If the IAB has
+ cause to publish a document as a Best Current Practice (BCP), it
+ would fall under the approval process of the IETF standards stream of
+ RFCs (see [RFC4844]).
+
+2. Review and Approval
+
+ In many cases, the IAB publishes documents to provide a permanent
+ record of an IAB statement or position. In such cases, the IAB uses
+ its internal discussion processes to refine the expression and
+ technical content of the document, and the document is approved for
+ publication if, and only if, the IAB is in agreement on its
+ substantive content.
+
+ For certain documents, it may not be appropriate for the IAB to take
+ responsibility for technical correctness. For example, where the IAB
+ has sponsored a workshop in which not all the participants were
+ members of the IAB and/or not all the members of the IAB were
+ present, approval by the IAB of a report of the workshop is used only
+ to assert that the report is a faithful report of the proceedings of
+ the workshop and that the matter is of interest to the community.
+
+ Documents for which the IAB takes responsibility for technical
+ correctness (the most usual case) will be indicated by noting the IAB
+ as an author of the document, with individuals noted as editors or
+ text authors. Other documents, such as workshop reports, will not
+ specify the IAB as an author (although this does not preclude
+ individual IAB members from being authors or editors).
+
+
+
+
+Daigle & IAB Informational [Page 2]
+
+RFC 4845 IAB RFC Publication Process July 2007
+
+
+ In general, the document (introductory) text should make plain the
+ role of the IAB in publishing and supporting the text. Should the
+ IAB have significant issues with any individual item in the document,
+ a note may be included in the document explaining the issue.
+
+3. IAB RFC Publication Process
+
+ The following is a description of the process used by the IAB to
+ publish IAB documents as RFCs.
+
+ 1. The document is determined to be an IAB document by the IAB, as
+ described in Section 1.
+
+ 2. The IAB publishes an IAB draft (draft-iab-*). Comments on the
+ draft are reviewed and may be integrated into successive
+ iterations of the draft. In addition to considering comments
+ received on the draft, the IAB may elect to refer the document to
+ individuals or groups and explicitly solicit comments as
+ appropriate.
+
+ 3. For documents intended to be published as BCPs, the document is
+ passed to the Internet Engineering Steering Group (IESG) with a
+ sponsoring Area Director (AD), and follows the process outlined
+ in [SPONSOR].
+
+ 4. For documents intended to be Informational RFCs, the remainder of
+ this process is followed.
+
+ 5. The chair of the IAB issues an IETF-wide Call for Comment on the
+ IETF Announce mailing list. The comment period is normally no
+ shorter than four weeks.
+
+ 6. Comments received are considered for integration into the
+ document. The IAB shall determine whether the document is ready
+ for publication based on the comments received, or whether
+ another round of document editing and, optionally, a further call
+ for input is required.
+
+ 7. The document is passed to the RFC Editor for publication as an
+ IAB document Informational RFC.
+
+4. Security Considerations
+
+ This document does not discuss matters with any particular security
+ implications.
+
+
+
+
+
+
+Daigle & IAB Informational [Page 3]
+
+RFC 4845 IAB RFC Publication Process July 2007
+
+
+5. IAB Members at the Time of Approval
+
+ Bernard Aboba
+ Loa Andersson
+ Brian Carpenter
+ Leslie Daigle
+ Elwyn Davies
+ Kevin Fall
+ Olaf Kolkman
+ Kurtis Lindqvist
+ David Meyer
+ David Oran
+ Eric Rescorla
+ Dave Thaler
+ Lixia Zhang
+
+6. References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", RFC 2026, BCP 9, October 1996.
+
+ [RFC4844] Daigle, L., Ed., "The RFC Series and RFC Editor",
+ RFC 4844, July 2007.
+
+ [SPONSOR] Arkko, J., Ed., "Guidance on Area Director Sponsoring of
+ Documents", ION, May 2007.
+
+Authors' Addresses
+
+ Leslie L. Daigle (editor)
+
+ EMail: ledaigle@cisco.com, leslie@thinkingcat.com
+
+
+ (IAB)
+
+ EMail: iab@iab.org
+ URI: http://www.iab.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 4]
+
+RFC 4845 IAB RFC Publication Process July 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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, THE IETF TRUST 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 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 5]
+