diff options
Diffstat (limited to 'doc/rfc/rfc5741.txt')
| -rw-r--r-- | doc/rfc/rfc5741.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc5741.txt b/doc/rfc/rfc5741.txt new file mode 100644 index 0000000..8ae1a40 --- /dev/null +++ b/doc/rfc/rfc5741.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Architecture Board (IAB) L. Daigle, Ed. +Request for Comments: 5741 O. Kolkman, Ed. +Updates: 2223, 4844 For the IAB +Category: Informational December 2009 +ISSN: 2070-1721 + + + RFC Streams, Headers, and Boilerplates + +Abstract + + RFC documents contain a number of fixed elements such as the title + page header, standard boilerplates, and copyright/IPR statements. + This document describes them and introduces some updates to reflect + current usage and requirements of RFC publication. In particular, + this updated structure is intended to communicate clearly the source + of RFC creation and review. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. Documents approved for publication by + the IAB are not a candidate for any level of Internet Standard; see + Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5741. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + + + +Daigle, et al. Informational [Page 1] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. RFC Streams and Internet Standards . . . . . . . . . . . . . . 3 + 3. RFC Structural Elements . . . . . . . . . . . . . . . . . . . 3 + 3.1. The Title Page Header . . . . . . . . . . . . . . . . . . 3 + 3.2. The Status of this Memo . . . . . . . . . . . . . . . . . 5 + 3.2.1. Paragraph 1 . . . . . . . . . . . . . . . . . . . . . 6 + 3.2.2. Paragraph 2 . . . . . . . . . . . . . . . . . . . . . 6 + 3.2.3. Paragraph 3 . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.4. Noteworthy . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3. Additional Notes . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. Other Structural Information in RFCs . . . . . . . . . . . 9 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 5. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 10 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Appendix A. Some Example 'Status of This Memo' Boilerplates . . . 12 + A.1. IETF Standards Track . . . . . . . . . . . . . . . . . . . 12 + A.2. IETF Experimental, with Consensus Call . . . . . . . . . . 12 + A.3. IETF Experimental, No Consensus Call . . . . . . . . . . . 13 + A.4. IAB Informational . . . . . . . . . . . . . . . . . . . . 13 + A.5. IRTF Experimental, No Consensus Call . . . . . . . . . . . 14 + A.6. Independent Submission Informational . . . . . . . . . . . 15 + Appendix B. IAB Members at Time of Approval . . . . . . . . . . . 15 + Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 + +1. Introduction + + Previously, RFCs (e.g., [RFC4844]) contained a number of elements + that were there for historical, practical, and legal reasons. They + also contained boilerplate material to clearly indicate the status of + the document and possibly contained "Notes" to indicate how the + document interacts with IETF Standards Track documents. + + As the RFC Series has evolved over the years, there has been + increasing concern over appropriate labeling of the publications to + make clear the status of each RFC and the status of the work it + describes. Chiefly, there is a requirement that RFCs published as + part of the IETF's review process not be easily confused with RFCs + that may have had a very different review and approval process. + Various adjustments have been made over the years, including evolving + text of "Notes" included in the published RFC. + + With the definition of the different RFC streams [RFC4844], it is + appropriate to formalize the definition of the various pieces of + standard RFC boilerplate and introduce some adjustments to ensure + + + +Daigle, et al. Informational [Page 2] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + + better clarity of expression of document status, aligned with the + review and approval processes defined for each stream. + + This memo identifies and describes the common elements of RFC + boilerplate structure, and provides a comprehensive approach to + updating and using those elements to communicate, with clarity, RFC + document and content status. Most of the historical structure + information is collected from [RFC2223]. + + The changes introduced by this memo should be implemented as soon as + practically possible after the document has been approved for + publication. + +2. RFC Streams and Internet Standards + + Users of RFCs should be aware that while all Internet Standards- + related documents are published as RFCs, not all RFCs are Internet + Standards-related documents. + + The IETF is responsible for maintaining the Internet Standards + Process, which includes the requirements for developing, reviewing, + and approving Standards Track and BCP RFCs. The IETF also produces + non-Standards-Track documents (Informational, Experimental, and + Historic). All documents published as part of the IETF Stream are + reviewed by the appropriate IETF bodies. + + Documents published in streams other than the IETF Stream are not + generally reviewed by the IETF for such things as security, + congestion control, or inappropriate interaction with deployed + protocols. They have also not been subject to approval by the + Internet Engineering Steering Group (IESG), including an IETF-wide + last call. Therefore, the IETF disclaims, for any of the non-IETF + Stream documents, any knowledge of the fitness of those RFCs for any + purpose. + + Refer to [RFC2026], [RFC5742], and [RFC4844] and their successors for + current details of the IETF process and RFC streams. + +3. RFC Structural Elements + +3.1. The Title Page Header + + This section describes the elements that are commonly found in RFCs + published today. For the sake of clarity, this document specifies + the elements precisely as a specification. However, this is not + intended to specify a single, static format. Details of formatting + are decided by the RFC Editor. Substantive changes to the header and + + + + +Daigle, et al. Informational [Page 3] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + + boilerplate structure and content may be undertaken in the future, + and are subject to general oversight and review by the IAB. + + An RFC title page header can be described as follows: + +------------------------------------------------------------------------ +<document source> <author name> +Request for Comments: <RFC number> [<author affiliation>] +[<subseries ID> <subseries number>] [more author info as appropriate] +[<RFC relation>:<RFC number[s]>] +Category: <category> + <month year> +------------------------------------------------------------------------ + + For example, a sample earlier RFC header is as follows: + +------------------------------------------------------------------------ +Network Working Group T. Dierks +Request for Comments: 4346 Independent +Obsoletes: 2246 E. Rescorla +Category: Standards Track RTFM, Inc. + April 2006 +------------------------------------------------------------------------ + + The right column contains author name and affiliation information as + well as the RFC publication month. Conventions and restrictions for + these elements are described in RFC style norms and some individual + stream definitions. + + This section is primarily concerned with the information in the left + column: + + <document source> + This describes the area where the work originates. Historically, + all RFCs were labeled Network Working Group. "Network Working + Group" refers to the original version of today's IETF when people + from the original set of ARPANET sites and whomever else was + interested -- the meetings were open -- got together to discuss, + design, and document proposed protocols [RFC0003]. Here, we + obsolete the term "Network Working Group" in order to indicate the + originating stream. + + The <document source> is the name of the RFC stream, as defined in + [RFC4844] and its successors. At the time of this publication, + the streams, and therefore the possible entries are: + + + + + + +Daigle, et al. Informational [Page 4] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + + * Internet Engineering Task Force (IETF) + + * Internet Architecture Board (IAB) + + * Internet Research Task Force (IRTF) + + * Independent Submission + + Request for Comments: <RFC number> + This indicates the RFC number, assigned by the RFC Editor upon + publication of the document. This element is unchanged. + + <subseries ID> <subseries number> + Some document categories are also labeled as a subseries of RFCs. + These elements appear as appropriate for such categories, + indicating the subseries and the documents number within that + series. Currently, there are subseries for BCPs [RFC2026], STDs + [RFC1311], and FYIs [RFC1150]. These subseries numbers may appear + in several RFCs. For example, when a new RFC obsoletes or updates + an old one, the same subseries number is used. Also, several RFCs + may be assigned the same subseries number: a single STD, for + example, may be composed of several RFCs, each of which will bear + the same STD number. This element is unchanged. + + [<RFC relation>: <RFC number[s]>] + Some relations between RFCs in the series are explicitly noted in + the RFC header. For example, a new RFC may update one or more + earlier RFCs. Currently two relationships are defined: "Updates" + and "Obsoletes" [RFC2223]. Alternatives like "Obsoleted by" are + also used (e.g., in [RFC5143]). Other types of relationships may + be defined by the RFC Editor and may appear in future RFCs. + + Category: <category> + This indicates the initial RFC document category of the + publication. These are defined in [RFC2026]. Currently, this is + always one of: Standards Track, Best Current Practice, + Experimental, Informational, or Historic. This element is + unchanged. + +3.2. The Status of this Memo + + The "Status of This Memo" describes the category of the RFC, + including the distribution statement. This text is included + irrespective of the source stream of the RFC. + + The "Status of This Memo" will start with a single sentence + describing the status. It will also include a statement describing + the stream-specific review of the material (which is stream- + + + +Daigle, et al. Informational [Page 5] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + + dependent). This is an important component of status, insofar as it + clarifies the breadth and depth of review, and gives the reader an + understanding of how to consider its content. + +3.2.1. Paragraph 1 + + The first paragraph of the Status of this Memo section contains a + single sentence, clearly standing out. It depends on the category of + the document. + + For 'Standards Track' documents: + "This is an Internet Standards Track document." + + For 'Best Current Practices' documents: + "This memo documents an Internet Best Current Practice." + + For other categories: + "This document is not an Internet Standards Track specification; + <it is published for other purposes>." + + For Informational, Experimental, Historic and future categories of + RFCs, the RFC Editor will maintain an appropriate text for <it is + published for other purposes>. Suggested initial values are: + + Informational: + "it is published for informational purposes." + + Historic: + "it is published for the historical record." + + Experimental: + "it is published for examination, experimental implementation, and + evaluation." + +3.2.2. Paragraph 2 + + The second paragraph of the "Status of This Memo" will now include a + paragraph describing the type of review and exposure the document has + received. This is defined on a per-stream basis, subject to general + review and oversight by the RFC Editor and IAB. There is a specific + structure defined here to ensure there is clarity about review + processes and document types. These paragraphs will need to be + defined and maintained as part of RFC stream definitions. Suggested + initial text, for current streams, is provided below. + + The paragraph may include some text that is specific to the initial + document category; when a document is Experimental or Historic, the + second paragraph opens with: + + + +Daigle, et al. Informational [Page 6] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + + Experimental: + "This document defines an Experimental Protocol for the Internet + community." + + Historic: + "This document defines a Historic Document for the Internet + community." + + The text that follows is stream dependent -- these are suggested + initial values and may be updated by stream definition document + updates. + + IETF Stream: + "This document is a product of the Internet Engineering Task Force + (IETF)." + + If there has been an IETF consensus call per IETF process, an + additional sentence should be added: + + "It represents the consensus of the IETF community. It has + received public review and has been approved for publication by + the Internet Engineering Steering Group (IESG)." + + If there has not been such a consensus call, then this simply + reads: + + "It has been approved for publication by the Internet + Engineering Steering Group (IESG)." + + IAB Stream: + "This document is a product of the Internet Architecture Board + (IAB) and represents information that the IAB has deemed valuable + to provide for permanent record." + + IRTF Stream: + "This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment." + + In addition, a sentence indicating the consensus base within the + IRTF may be added: + + "This RFC represents the consensus of the <insert_name> + Research Group of the Internet Research Task Force (IRTF)." + + or alternatively + + + + +Daigle, et al. Informational [Page 7] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + + "This RFC represents the individual opinion(s) of one or more + members of the <insert_name> Research Group of the Internet + Research Task Force (IRTF)." + + Independent Stream: + "This is a contribution to the RFC Series, independently of any + other RFC stream. The RFC Editor has chosen to publish this + document at its discretion and makes no statement about its value + for implementation or deployment." + + For non-IETF stream documents, a reference to Section 2 of this RFC + is added with the following sentence: + + "Documents approved for publication by the [stream approver -- + currently, one of: "IAB", "IRSG", or "RFC Editor"] are not a + candidate for any level of Internet Standard; see Section 2 of RFC + 5741." + + For IETF stream documents, a similar reference is added for BCP and + Standards Track documents: + + "Further information on [BCPs or Internet Standards] is available + in Section 2 of RFC 5741." + + For all other categories: + + "Not all documents approved by the IESG are a candidate for any + level of Internet Standard; see Section 2 of RFC 5741." + +3.2.3. Paragraph 3 + + The boilerplate ends with a reference to where further relevant + information can be found. This information may include, subject to + the RFC Editor's discretion, information about whether the RFC has + been updated or obsoleted, the RFC's origin, a listing of possible + errata, information about how to provide feedback and suggestion, and + information on how to submit errata as described in [RFC-ERRATA]. + The exact wording and URL is subject to change (at the RFC Editor's + discretion), but current text is: + + "Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc<rfc-no>." + + + + + + + + +Daigle, et al. Informational [Page 8] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + +3.2.4. Noteworthy + + Note that the text in paragraph 1 and 2 of the boilerplate indicate + the initial status of a document. During their lifetime, documents + can change status to e.g., Historic. This cannot be reflected in the + document itself and will need be reflected in the information + referred to in Section 3.2.3. + +3.3. Additional Notes + + Exceptionally, a review and publication process may prescribe + additional notes that will appear as labeled notes after the "Status + of This Memo". + + While this has been a common feature of recent RFCs, it is the goal + of this document to make the overall RFC structure adequately clear + to remove the need for such notes, or at least make their usage truly + exceptional. + +3.4. Other Structural Information in RFCs + + RFCs contain other structural informational elements. The RFC Editor + is responsible for the positioning and layout of these structural + elements. Note also that new elements may be introduced or obsoleted + using a process consistent with [RFC4844]. These additions may or + may not require documentation in an RFC. + + Currently the following structural information is available or is + being considered for inclusion in RFCs: + + Copyright Notice + A copyright notice with a reference to BCP 78 [BCP78] and an + Intellectual Property statement referring to BCP 78 and BCP 79 + [BCP79]. The content of these statements are defined by those + BCPs. + + ISSN + The International Standard Serial Number [ISO3297]: + ISSN 2070-1721. The ISSN uniquely identifies the RFC series as + title regardless of language or country in which it is published. + The ISSN itself has no significance other than the unique + identification of a serial publication. + +4. Security Considerations + + This document tries to clarify the descriptions of the status of an + RFC. Misunderstanding the status of a memo could cause + interoperability problems, hence security and stability problems. + + + +Daigle, et al. Informational [Page 9] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + +5. RFC Editor Considerations + + The RFC Editor is responsible for maintaining the consistency of the + RFC series. To that end the RFC Editor maintains a style manual + [RFC-style]. In this memo we mention a few explicit structural + elements that the RFC Editor needs to maintain. The conventions for + the content and use of all current and future elements are to be + documented in the style manual. + + Adding a reference to the stream in the header of RFCs is only one + method for clarifying from which stream an RFC originated. The RFC + Editor is encouraged to add such indication in e.g., indices and + interfaces. + +6. References + +6.1. Normative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for + Handling of Independent and IRTF Stream Submissions", + BCP 92, RFC 5742, December 2009. + +6.2. Informative References + + [ISO3297] Technical Committee ISO/TC 46, Information and + documentation, Subcommittee SC 9, Identification and + description., "Information and documentation - + International standard serial number (ISSN)", 09 2007. + + [RFC0003] Crocker, S., "Documentation conventions", RFC 3, + April 1969. + + [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, + March 1992. + + [RFC1150] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction + to the FYI Notes", RFC 1150, March 1990. + + [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC + Authors", RFC 2223, October 1997. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + + + + +Daigle, et al. Informational [Page 10] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + + [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC + Series and RFC Editor", RFC 4844, July 2007. + + [RFC5143] Malis, A., Brayley, J., Shirron, J., Martini, L., and + S. Vogelsang, "Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation Service + over MPLS (CEM) Encapsulation", RFC 5143, + February 2008. + + [RFC-ERRATA] Hagens, A., Ginoza, S., and R. Braden, "RFC Editor + Proposal for Handling RFC Errata", Work in Progress, + May 2008. + + [BCP78] Bradner, S., Ed. and J. Contreras, Ed., "Rights + Contributors Provide to the IETF Trust", BCP 78, + RFC 5378, November 2008. + + [BCP79] Bradner, S., Ed. and T. Narten, Ed., "Intellectual + Property Rights in IETF Technology", BCP 79, RFC 3979, + April 2007. + + Narten, T., "Clarification of the Third Party + Disclosure Procedure in RFC 3979", BCP 79, RFC 4879, + April 2007. + + [RFC-style] RFC Editor, "RFC Style Guide", + <http://www.rfc-editor.org/styleguide.html>. + + + + + + + + + + + + + + + + + + + + + + + + +Daigle, et al. Informational [Page 11] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + +Appendix A. Some Example 'Status of This Memo' Boilerplates + +A.1. IETF Standards Track + + The boilerplate for a Standards Track document that (by definition) + has been subject to an IETF consensus call. + +------------------------------------------------------------------------ +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by + the Internet Engineering Steering Group (IESG). Further + information on Internet Standards is available in Section 2 of + RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc<rfc-no>. +------------------------------------------------------------------------ + +A.2. IETF Experimental, with Consensus Call + + The boilerplate for an Experimental document that has been subject to + an IETF consensus call. + +------------------------------------------------------------------------ +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc<rfc-no>. +------------------------------------------------------------------------ + + + +Daigle, et al. Informational [Page 12] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + +A.3. IETF Experimental, No Consensus Call + + The boilerplate for an Experimental document that not has been + subject to an IETF consensus call. + +------------------------------------------------------------------------ +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc<rfc-no>. +------------------------------------------------------------------------ + +A.4. IAB Informational + + The boilerplate for an Informational IAB document. + +------------------------------------------------------------------------ +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board + (IAB) and represents information that the IAB has deemed valuable + to provide for permanent record. Documents approved for publication + by the IAB are not a candidate for any level of Internet Standard; + see Section 2 of RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc<rfc-no>. +------------------------------------------------------------------------ + + + + + + + +Daigle, et al. Informational [Page 13] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + +A.5. IRTF Experimental, No Consensus Call + + The boilerplate for an Experimental document that has been produced + by the IRTF and for which there was no RG consensus. This variation + is the most verbose boilerplate in the current set. + +------------------------------------------------------------------------ +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the individual + opinion(s) of one or more members of the <insert_name> Research Group + of the Internet Research Task Force (IRTF). Documents approved for + publication by the IRSG are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc<rfc-no>. +------------------------------------------------------------------------ + + + + + + + + + + + + + + + + + + + + + + + + +Daigle, et al. Informational [Page 14] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + +A.6. Independent Submission Informational + + The boilerplate for an Informational document that has been produced + by the Independent Submission stream. + +------------------------------------------------------------------------ +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any + other RFC stream. The RFC Editor has chosen to publish this + document at its discretion and makes no statement about its value + for implementation or deployment. Documents approved for + publication by the RFC Editor are not a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc<rfc-no>. +------------------------------------------------------------------------ + +Appendix B. IAB Members at Time of Approval + + The IAB members at the time this memo was approved were (in + alphabetical order): Loa Andersson, Gonzalo Camarillo, Stuart + Cheshire, Russ Housley, Olaf Kolkman, Gregory Lebovitz, Barry Leiba, + Kurtis Lindqvist, Andrew Malis, Danny McPherson, David Oran, Dave + Thaler, and Lixia Zhang. In addition, the IAB included two + ex-officio members: Dow Street, who was serving as the IAB Executive + Director, and Aaron Falk, who was serving as the IRTF Chair. + +Appendix C. Acknowledgements + + Thanks to Bob Braden, Brian Carpenter, Steve Crocker, Sandy Ginoza, + and John Klensin who provided background information and inspiration. + + Various people have made suggestions that improved the document. + Among them are: Lars Eggert, Alfred Hoenes, and Joe Touch. + + This document was produced using the xml2rfc tool [RFC2629]. + + + + + + + + + +Daigle, et al. Informational [Page 15] + +RFC 5741 RFC Streams, Headers, Boilerplates December 2009 + + +Authors' Addresses + + Leslie Daigle (editor) + EMail: daigle@isoc.org, leslie@thinkingcat.com + + + Olaf M. Kolkman (editor) + EMail: olaf@nlnetlabs.nl + + + Internet Architecture Board + EMail: iab@iab.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daigle, et al. Informational [Page 16] + |