< draft-iab-streams-headers-boilerplates-01.txt   draft-iab-streams-headers-boilerplates-02.txt >
Network Working Group L. Daigle, Ed. Network Working Group L. Daigle, Ed.
Internet-Draft O. Kolkman, Ed. Internet-Draft O. Kolkman, Ed.
Updates: 4844, 2223 Updates: 4844, 2223
(if approved) Internet Architecture Board (if approved) Internet Architecture Board
Intended status: Informational (IAB) Intended status: Informational (IAB)
Expires: April 9, 2009 October 6, 2008 Expires: April 20, 2009 October 17, 2008
On RFC Streams, Headers, and Boilerplates On RFC Streams, Headers, and Boilerplates
draft-iab-streams-headers-boilerplates-01 draft-iab-streams-headers-boilerplates-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 9, 2009. This Internet-Draft will expire on April 20, 2009.
Abstract Abstract
RFC documents contain a number of fixed elements such as the title RFC documents contain a number of fixed elements such as the title
page header, standard boilerplates and copyright/IPR statements. page header, standard boilerplates and copyright/IPR statements.
This document describes them and introduces some updates to reflect This document describes them and introduces some updates to reflect
current usage and requirements of RFC publication. In particular, current usage and requirements of RFC publication. In particular,
this updated structure is intended to communicate clearly the source this updated structure is intended to communicate clearly the source
of RFC creation and review. of RFC creation and review.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RFC Streams and Internet Standards . . . . . . . . . . . . . . 3 2. RFC Streams and Internet Standards . . . . . . . . . . . . . . 3
3. RFC Structural Elements . . . . . . . . . . . . . . . . . . . 4 3. RFC Structural Elements . . . . . . . . . . . . . . . . . . . 4
3.1. The title page header . . . . . . . . . . . . . . . . . . 4 3.1. The title page header . . . . . . . . . . . . . . . . . . 4
3.2. The Status of this Memo . . . . . . . . . . . . . . . . . 6 3.2. The Status of this Memo . . . . . . . . . . . . . . . . . 6
3.3. Additional Notes . . . . . . . . . . . . . . . . . . . . . 8 3.3. Additional Notes . . . . . . . . . . . . . . . . . . . . . 8
3.4. Other structural information in RFCs . . . . . . . . . . . 8 3.4. Other structural information in RFCs . . . . . . . . . . . 8
4. Security considerations . . . . . . . . . . . . . . . . . . . 9 4. Security considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
6. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 9 6. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Appendix A. IAB members at time of approval . . . . . . . . . . . 11
Appendix B. Document Editing Details . . . . . . . . . . . . . . 10 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11
B.1. version 00->01 . . . . . . . . . . . . . . . . . . . . . . 11 Appendix C. Document Editing Details . . . . . . . . . . . . . . 12
B.1.1. open issues . . . . . . . . . . . . . . . . . . . . . 11 C.1. version 00->01 . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 C.2. version 01->02 . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
Previously RFCs (e.g. [RFC4844]) contained a number of elements that Previously RFCs (e.g. [RFC4844]) contained a number of elements that
were there for historical, practical, and legal reasons. They also were there for historical, practical, and legal reasons. They also
contained boilerplate material to clearly indicate the status of the contained boilerplate material to clearly indicate the status of the
document and possibly contained "Notes" to indicate how the document document and possibly contained "Notes" to indicate how the document
interacts with IETF standard track documents. interacts with IETF Standards-Track documents.
As the RFC Series has evolved over the years, there has been As the RFC Series has evolved over the years, there has been
increasing concern over appropriate labelling of the publications to increasing concern over appropriate labelling of the publications to
make clear the status of each RFC and the status of the work it make clear the status of each RFC and the status of the work it
describes. Chiefly, there is a requirement that RFCs published as describes. Chiefly, there is a requirement that RFCs published as
part of the IETF's review process not be easily confused with RFCs part of the IETF's review process not be easily confused with RFCs
that may have had a very different review and approval process. that may have had a very different review and approval process.
Various adjustments have been made over the years, including evolving Various adjustments have been made over the years, including evolving
text of "Notes" included in the published RFC. text of "Notes" included in the published RFC.
skipping to change at page 4, line 6 skipping to change at page 4, line 6
The IETF is responsible for maintaining the Internet Standards The IETF is responsible for maintaining the Internet Standards
Process, which includes the requirements for developing, reviewing Process, which includes the requirements for developing, reviewing
and approving Standards Track and BCP RFCs. These, and any other and approving Standards Track and BCP RFCs. These, and any other
standards-related documents (Informational or Experimental) are standards-related documents (Informational or Experimental) are
reviewed by appropriate IETF bodies and published as part of the IETF reviewed by appropriate IETF bodies and published as part of the IETF
Stream. Stream.
Documents published in streams other than the IETF Stream are not Documents published in streams other than the IETF Stream are not
reviewed by the IETF for such things as security, congestion control, reviewed by the IETF for such things as security, congestion control,
or inappropriate interaction with deployed protocols. They have also or inappropriate interaction with deployed protocols. They have also
not been subject to IESG approval, including an IETF-wide last call. not been subject to approval by the Internet Engineering Steering
Therefore, the IETF disclaims, for any of the non-IETF Stream Group (IESG), including an IETF-wide last call. Therefore, the IETF
documents, any knowledge of the fitness of those RFCs for any disclaims, for any of the non-IETF Stream documents, any knowledge of
purpose. the fitness of those RFCs for any purpose.
Refer to [RFC2026], [I-D.housley-iesg-rfc3932bis], and [RFC4844] and Refer to [RFC2026], [I-D.housley-iesg-rfc3932bis], and [RFC4844] and
their successors for current details of IETF process and RFC streams. their successors for current details of the IETF process and RFC
streams.
3. RFC Structural Elements 3. RFC Structural Elements
3.1. The title page header 3.1. The title page header
An RFC title page header can be described as follows: An RFC title page header can be described as follows:
------------------------------------------------------------------------ ------------------------------------------------------------------------
<document source> <author name> <document source> <author name>
Request for Comments: <RFC number> [<author affiliation>] Request for Comments: <RFC number> [<author affiliation>]
skipping to change at page 5, line 10 skipping to change at page 5, line 10
definitions. definitions.
This section is primarily concerned with the information in the left This section is primarily concerned with the information in the left
column: column:
<document source> This describes the area where the work originates. <document source> This describes the area where the work originates.
Historically, all RFCs were labeled Network Working Group. Historically, all RFCs were labeled Network Working Group.
"Network Working Group" refers to the original version of today's "Network Working Group" refers to the original version of today's
IETF when people from the original set of ARPANET sites and IETF when people from the original set of ARPANET sites and
whomever else was interested -- the meetings were open -- got whomever else was interested -- the meetings were open -- got
together to discuss, design and document proposed together to discuss, design and document proposed protocols
protocols[RFC0003]. Here, we obsolete the term "Network Working [RFC0003]. Here, we obsolete the term "Network Working Group" in
Group" in order to indicate the originating stream. order to indicate the originating stream.
The <document source> is the name of the RFC stream, as defined in The <document source> is the name of the RFC stream, as defined in
[RFC4844] and its successors. At the time of this publication, [RFC4844] and its successors. At the time of this publication,
the streams, and therefore the possible entries are: the streams, and therefore the possible entries are:
* Internet Engineering Task Force * Internet Engineering Task Force
* Internet Architecture Board * Internet Architecture Board
* Internet Research Task Force * Internet Research Task Force
skipping to change at page 5, line 34 skipping to change at page 5, line 34
* Independent * Independent
Request for Comments: <RFC number> This indicates the RFC number, Request for Comments: <RFC number> This indicates the RFC number,
assigned by the RFC Editor upon publication of the document. This assigned by the RFC Editor upon publication of the document. This
element is unchanged. element is unchanged.
<subseries ID> <subseries number> Some document categories are also <subseries ID> <subseries number> Some document categories are also
labeled as a subseries of RFCs. These elements appear as labeled as a subseries of RFCs. These elements appear as
appropriate for such categories, indicating the subseries and the appropriate for such categories, indicating the subseries and the
documents number within that series. Currently, there are documents number within that series. Currently, there are
subseries for BCPs, STDs and FYIs. These subseries numbers may subseries for BCPs [RFC2026], STDs[RFC1311], and FYIs [RFC1150].
appear in several RFCs. For example, when a new RFC updates an These subseries numbers may appear in several RFCs. For example,
old one, the same subseries number is used. Also, several RFCs when a new RFC obsoletes or updates an old one, the same subseries
may be assigned the same subseries number: a single STD, for number is used. Also, several RFCs may be assigned the same
example, may be composed of several RFCs, each of which will bear subseries number: a single STD, for example, may be composed of
the same STD number. This element is unchanged. 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 [<RFC relation>:<RFC number[s]>] Some relations between RFCs in the
series are explicitly noted in the RFC header. For example, a new series are explicitly noted in the RFC header. For example, a new
RFC may update one or more earlier RFCs. Currently two RFC may update one or more earlier RFCs. Currently two
relationships are defined "Updates" and "Obsoletes". Other types relationships are defined: "Updates", and "Obsoletes" [RFC2223].
of relations may be defined elsewhere. Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
Other types of relations may be defined elsewhere.
Category: <category> This indicates the RFC document category of the Category: <category> This indicates the initial RFC document
publication. These are defined in [RFC2026]. Currently, this is category of the publication. These are defined in [RFC2026].
always one of: Standards Track, Best Current Practice, Currently, this is always one of: Standards Track, Best Current
Experimental, Informational, or Historic. This element is Practice, Experimental, Informational, or Historic. This element
unchanged. is unchanged.
3.2. The Status of this Memo 3.2. The Status of this Memo
The "Status of This Memo" describes the category of the RFC, The "Status of This Memo" describes the category of the RFC,
including the distribution statement. This text is included including the distribution statement. This text is included
irrespective of the source stream of the RFC. irrespective of the source stream of the RFC.
From now on, the "Status of This Memo" will start with a single line From now on, the "Status of This Memo" will start with a single
describing the status. It will also include a statement describing sentence describing the status. It will also include a statement
the stream-specific review of the material (which is stream- describing the stream-specific review of the material (which is
dependent). This is an important component of status, insofar as it stream-dependent). This is an important component of status, insofar
clarifies the breadth and depth of review, and gives the reader an as it clarifies the breadth and depth of review, and gives the reader
understanding of how to consider its content. an understanding of how to consider its content.
The first paragraph of the Status of this Memo section contains a The first paragraph of the Status of this Memo section contains a
single line, clearly standing out. It depends on the category of the single sentence, clearly standing out. It depends on the category of
document. the document.
This memo is an Internet Standards Track document. This memo is an Internet Standards Track document.
This memo documents an Internet Best Current Practice This memo documents an Internet Best Current Practice
This memo is not an Internet Standards Track specifiation, <it is This memo is not an Internet Standards Track specification, <it is
published for other purposes>. published for other purposes>.
For Informational, Experimental and other future categories of RFC For Informational, Experimental, Historic and future categories of
editor will maintain an appropriate text for <it is published for RFCs, the RFC editor will maintain an appropriate text for <it is
other purposes>. For example, with an Informational document this published for other purposes>. For example, with an Informational
could read "It is published for informational purposes". document this could read "it is published for informational
purposes".
This indicates the RFC number, assigned by the RFC Editor upon
publication of the document. This element is unchanged.
The second paragraph contains category-specific text as follows: The second paragraph contains text as follows that is specific to the
initial category:
Standards Track: "This document specifies an Internet standards Standards Track: "This document specifies an Internet standards
track protocol for the Internet community. Please see the track protocol for the Internet community. Please see the
"Updates to the RFC" section of this document for information on "Updates to the RFC" section of this document for information on
where to find the status of this protocol and the availability of where to find the status of this document and the availability of
errata for this memo." errata for this memo."
Best Current Practice: "This document specifies an Internet Best Best Current Practice: "This document specifies an Internet Best
Current Practices for the Internet Community. Please see the Current Practices for the Internet Community. Please see the
"Updates to the RFC" section of this document for information on "Updates to the RFC" section of this document for information on
where to find the status of this protocol and the availability of where to find the status of this document and the availability of
errata for this memo." errata for this memo."
Experimental: "This memo defines an Experimental Protocol for the Experimental: "This memo defines an Experimental Protocol for the
Internet community. This memo does not specify an Internet Internet community. This memo does not specify an Internet
standard of any kind. Discussion and suggestions for improvement standard of any kind. Discussion and suggestions for improvement
are requested." are requested."
Informational: "This memo provides information for the Internet Informational: "This memo provides information for the Internet
community. This memo does not specify an Internet standard of any community. This memo does not specify an Internet standard of any
kind. " kind. "
Historic: "This memo defines a Historic Document for the Internet
community. It does not specify an Internet standard of any kind."
Note that the texts 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 refered
to in Section 3.4.
The third paragraph of the "Status of This Memo" will now include a The third paragraph of the "Status of This Memo" will now include a
paragraph describing the type of review and exposure the document has paragraph describing the type of review and exposure the document has
received. This is defined on a per-stream basis. From now on, these received. This is defined on a per-stream basis. From now on, these
paragraphs will be defined as part of RFC stream definition. paragraphs will be defined as part of RFC stream definitions.
The following texts may be updated if the stream definitions are The following texts may be updated if the stream definitions are
updated, but initial paragraphs for the existing streams are: updated, but initial paragraphs for the existing streams are:
IETF Stream: "This document is a product of the Internet Engineering IETF Stream: "This document is a product of the Internet Engineering
Task Force (IETF). " Task Force (IETF). "
If there has been an IETF consensus call per IETF process, an If there has been an IETF consensus call per IETF process, an
additional sentence should be added: "This document represents a additional sentence should be added: "This document represents a
consensus of the IETF community. It has received public review consensus of the IETF community. It has received public review
and has been approved for publication by the IESG." and has been approved for publication by the Internet Engineering
Steering Group."
IAB Stream: "This document is a product of the Internet Architecture IAB Stream: "This document is a product of the Internet Architecture
Board (IAB), and represents information that the IAB has deemed Board (IAB), and represents information that the IAB has deemed
valuable to provide for permanent record. This document has been valuable to provide for permanent record. This document has been
approved for publication by the IAB and is therefore not a approved for publication by the IAB and is therefore not a
candidate for any level of Internet Standard; see section candidate for any level of Internet Standard; see section
Section 2 of RFCXXXX." Section 2 of RFCXXXX."
IRTF Stream: "This document is a product of the Internet Research IRTF Stream: "This document is a product of the Internet Research
Task Force (IRTF). The IRTF publishes the results of Internet- Task Force (IRTF). The IRTF publishes the results of Internet-
skipping to change at page 8, line 19 skipping to change at page 8, line 27
therefore not a candidate for any level of Internet Standard; see therefore not a candidate for any level of Internet Standard; see
section Section 2 of RFCXXXX." section Section 2 of RFCXXXX."
3.3. Additional Notes 3.3. Additional Notes
Exceptionally, a review and publication process may prescribe Exceptionally, a review and publication process may prescribe
additional notes that will appear as labelled notes after the "Status additional notes that will appear as labelled notes after the "Status
of This Memo". of This Memo".
While this has been a common feature of recent RFCs, it is the goal While this has been a common feature of recent RFCs, it is the goal
of this exercise to make the overall RFC structure adequately clear 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 to remove the need for such notes, or at least make their usage truly
exceptional. exceptional.
3.4. Other structural information in RFCs 3.4. Other structural information in RFCs
RFCs contain other structural informational elements. The RFC Editor RFCs contain other structural informational elements. The RFC Editor
is responsible for the positioning and layout of these structural is responsible for the positioning and layout of these structural
element. Note also that new elements may be introduced or obsoleted element. Note also that new elements may be introduced or obsoleted
using a process consistent with [RFC4844]. These additions may or using a process consistent with [RFC4844]. These additions may or
may not require documentation in an RFC. may not require documentation in an RFC.
Currently the following structural information is available in RFCs. Currently the following structural information is available or is
being considered for inclusion in RFCs
Copyright Notice A copyright notice with a reference to BCP78 and an Copyright Notice A copyright notice with a reference to BCP78
Intellectual Property statement referring to BCP78 and BCP79. The [BCP78] and an Intellectual Property statement referring to BCP78
content of these statements are defined by those BCPs. and BCP79 [BCP79]. The content of these statements are defined by
those BCPs.
ISSN The International Standard Serial Number[ISO3297]: ISSN 2070- ISSN The International Standard Serial Number [ISO3297]: ISSN 2070-
1721. The ISSN uniquely identifies the RFC series as title 1721. The ISSN uniquely identifies the RFC series as title
regardless of language or country in which published. The ISSN regardless of language or country in which it is published. The
itself has no significance other than the unique identification of ISSN itself has no significance other than the unique
a serial publication. identification of a serial publication.
Updates to the RFC A reference identifying where more information Updates to the RFC A reference identifying where more information
about the document can be found. This includes information wether about the document can be found. This may include information
the RFC has been updated, obsoleted, or clarified, a listing of whether the RFC has been updated or obsoleted, the RFC's
possible errata, and information on how to submit errata as originating stream, a listing of possible errata, and information
described in [I-D.rfc-editor-errata-process]. on how to submit errata as described in
[I-D.rfc-editor-errata-process].
4. Security considerations 4. Security considerations
This document tries to clarify the descriptions of the status of an This document tries to clarify the descriptions of the status of an
RFC. Misunderstanding the status of a memo could cause RFC. Misunderstanding the status of a memo could cause
interoperability problems, hence security and stability problems. interoperability problems, hence security and stability problems.
5. IANA considerations 5. IANA considerations
None. None.
6. RFC Editor Considerations 6. RFC Editor Considerations
The RFC Editor is responsibile for maintaining the consistency of the The RFC Editor is responsible for maintaining the consistency of the
RFC series. To that end the RFC Editor maintains a style manual RFC series. To that end the RFC Editor maintains a style manual
[insert reference]. In this memo we mention a few explicit [RFC-style]. In this memo we mention a few explicit structural
structural elements that the RFC editor needs to maintain. The elements that the RFC editor needs to maintain. The conventions for
conventions for the content and use of all current and future the content and use of all current and future elements are to be
elements are to be documented in the style manual. 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.
[The rest of this section contains specific instructions towards [The rest of this section contains specific instructions towards
editing this document and can be removed before publication] editing this document and can be removed before publication]
The documents has two sections, including this one that need to be The documents has two sections, including this one that need to be
removed before publication as an RFC. This one and Appendix B. removed before publication as an RFC. This one and Appendix C.
This memo introduces a number of modifications that will have to be This memo introduces a number of modifications that will have to be
implemented in various tools, such as the xml2rfc tool, the nit implemented in various tools, such as the xml2rfc tool, the nit
tracker and the rfc-erratum portal. tracker and the rfc-erratum portal.
The number "XXXX" is to be replaced with RFC number of this memo. The number "XXXX" is to be replaced with RFC number of this memo.
References [RFC-style], [BCP78] and [BCP79] have been constructed.
Please bring these in line with RFC Editorial conventions.
In section Section 3.4: For the final publication, it should be
warranted that the ISSN is *not* split by a line break, for clarity.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[I-D.housley-iesg-rfc3932bis] [I-D.housley-iesg-rfc3932bis]
Alvestrand, H. and R. Housley, "IESG Procedures for Alvestrand, H. and R. Housley, "IESG Procedures for
Handling of Independent and IRTF Stream Submissions", Handling of Independent and IRTF Stream Submissions",
draft-housley-iesg-rfc3932bis-01 (work in progress), draft-housley-iesg-rfc3932bis-04 (work in progress),
August 2008. October 2008.
7.2. Informative References 7.2. Informative References
[ISO3297] Technical Committee ISO/TC 46, Information and [ISO3297] Technical Committee ISO/TC 46, Information and
documentation, Subcommittee SC 9, Identification and documentation, Subcommittee SC 9, Identification and
description., "Information and documentation - description. , "Information and documentation -
International standard serial number (ISSN)", 09 2007. International standard serial number (ISSN)" , 09 2007 .
[RFC0003] Crocker, S., "Documentation conventions", RFC 3, [RFC0003] Crocker, S. , "Documentation conventions" , RFC 3 ,
April 1969. April 1969 .
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", [RFC1311] Postel, J. , "Introduction to the STD Notes" , RFC 1311
RFC 2223, October 1997. , March 1992 .
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC1150] Malkin, G. and J. Reynolds , "FYI on FYI: Introduction
June 1999. to the FYI Notes" , RFC 1150 , March 1990 .
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC2223] Postel, J. and J. Reynolds , "Instructions to RFC
RFC 3978, March 2005. Authors" , RFC 2223 , October 1997 .
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC [RFC2629] Rose, M. , "Writing I-Ds and RFCs using XML" , RFC 2629
Series and RFC Editor", RFC 4844, July 2007. , June 1999 .
[I-D.rfc-editor-errata-process] [RFC3978] Bradner, S. , "IETF Rights in Contributions" , BCP 78 ,
Ginoza, S., Hagens, A., and R. Braden, "RFC Editor RFC 3978 , March 2005 .
Proposal for Handling RFC Errata",
draft-rfc-editor-errata-process-02 (work in progress),
May 2008.
Appendix A. Acknowledgements [RFC3979] Bradner, S. , "Intellectual Property Rights in IETF
Technology" , BCP 79 , RFC 3979 , March 2005 .
Thanks to Bob Braden, Brian Carpenter, Steve Crocker and John Klensin [RFC4844] Daigle, L. and Internet Architecture Board , "The RFC
who provided background information and inspiration. Series and RFC Editor" , RFC 4844 , July 2007 .
[RFC4748] Bradner, S. , "RFC 3978 Update to Recognize the IETF
Trust" , BCP 78 , RFC 4748 , October 2006 .
[RFC4749] Sollaud, A. , "RTP Payload Format for the G.729.1 Audio
Codec" , RFC 4749 , October 2006 .
[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 .
[I-D.rfc-editor-errata-process]
Ginoza, S. , Hagens, A. , and R. Braden , "RFC Editor
Proposal for Handling RFC Errata" ,
draft-rfc-editor-errata-process-02 (work in progress) ,
May 2008 .
[BCP78] Bradner, S., Ed. , "IETF Rights in Contributions" ,
BCP 78 , October 2006 .
[RFC3978]and[RFC4748]
[BCP79] Bradner, S., Ed. and T. Narten, Ed., "Intellectual
Property Rights in IETF Technology", BCP 79, April 2007.
[RFC3979]and[RFC4749]
[RFC-style]
RFC Editor, "RFC Style Guide",
<http://www.rfc-editor.org/howtopub.html>.
Appendix A. IAB members at time of approval
The IAB members at the time the RFC Editor model 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 B. 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. Various people have made suggestions that improved the document.
Among them are: Loa Andersson, Lars Eggert, Alfred Hines, Russ Among them are: Lars Eggert and Alfred Hoenes.
Housley, and David Oran.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
Appendix B. Document Editing Details Appendix C. Document Editing Details
[To Be Removed before publication] [To Be Removed before publication]
B.1. version 00->01 $Id: draft-iab-streams-headers-boilerplates-02.txt 42 2008-10-17 06:27:55Z olaf $
Fixed the header so it appropriatly shows that the document updates C.1. version 00->01
Fixed the header so it appropriately shows that the document updates
RFC 4844, 2223. And added a link to 3932-bis that should appear in RFC 4844, 2223. And added a link to 3932-bis that should appear in
tandem with this publication. tandem with this publication.
Introduced the "Other structural information in RFCs" section and Introduced the "Other structural information in RFCs" section and
moved the ISSN number from the front matter to this section. The moved the ISSN number from the front matter to this section. The
"Other structural information in RFCs" intends to give very rough "Other structural information in RFCs" intends to give very rough
guidance providing the RFC editor with sufficient freedom to move guidance providing the RFC editor with sufficient freedom to move
pieces around and edit them to please the eye and mind. pieces around and edit them to please the eye and mind.
Modified the last sentence 3rd paragraph of the Status of this memo Modified the last sentence 3rd paragraph of the Status of this memo
section for the IRTF Stream in accordance to a suggestion by Aaron section for the IRTF Stream in accordance to a suggestion by Aaron
Falk; Indicating that review happend by the IRSG and not indicating Falk; Indicating that review happened by the IRSG and not indicating
that review did not happen by the IESG. that review did not happen by the IESG.
Introduced the square brackets around the <author affiliation> in the Introduced the square brackets around the <author affiliation> in the
header. To highlight this is an optional elelment. header. To highlight this is an optional element.
The definition of the "Clarifies" relation has been taken out. There The definition of the "Clarifies" relation has been taken out. There
are arguments that introducing the relation needs a bit more thought are arguments that introducing the relation needs a bit more thought
and is better done by a seperate document. and is better done by a separate document.
Provided the RFC Editor with responsibility to maintain several text Provided the RFC Editor with responsibility to maintain several text
pieces. pieces.
In Section 3.2 some modifications were applied to the text. In Section 3.2 some modifications were applied to the text.
The <discription> contains the full name of the stream. The <description> contains the full name of the stream.
RFC2223 and 4844 moved to the informative reference section. RFC2223 and 4844 moved to the informative reference section.
Although I am not sure if those are not normative. Guidance!!! Although I am not sure if those are not normative. Guidance!!!
B.1.1. open issues C.2. version 01->02
Does the RFC Editor wants to supply text with respect to the level of Fixed some editorial nits and missing references.
review in Section 3.2 for the Independent Stream?
Clarified that the status and category are initial.
Added boilerplate text for documents that are initially published as
Historic.
Added members of IAB, and removed those members from acknowledgements
Added References to BCP78 and BCP79. The exact formatting of those
references may need to be done by the RFC editor.
Added text to recognize occurrences of variations of "Obsolete" and
"Update"
Authors' Addresses Authors' Addresses
Leslie Daigle (editor) Leslie Daigle (editor)
Email: daigle@isoc.org, leslie@thinkingcat.com Email: daigle@isoc.org, leslie@thinkingcat.com
Olaf M. Kolkman (editor) Olaf M. Kolkman (editor)
Email: olaf@nlnetlabs.nl Email: olaf@nlnetlabs.nl
Internet Architecture Board Internet Architecture Board
Email: iab@iab.org Email: iab@iab.org
Full Copyright Statement Full Copyright Statement
 End of changes. 55 change blocks. 
109 lines changed or deleted 195 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/