One document matched: draft-iab-rfc5741bis-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--
#
# draft-halpern-iab-rfc5741bis-02.xml
#
#
# Joel M. Halpern
# joel.halpern@ericsson.com
# 02-October-2015
#
-->
<?rfc subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902"
obsoletes="5741"
category="info"
docName="draft-iab-rfc5741bis-02"
>
<front>
<title abbrev="RFC Streams, Headers, Boilerplates">
On RFC Streams, Headers, and Boilerplates
</title>
<author role="editor" initials="J.M." surname = "Halpern" fullname="Joel M. Halpern">
<organization> </organization>
<address> <email>jmh@joelhalpern.com</email> </address>
</author>
<author role="editor" initials="L." surname="Daigle" fullname="Leslie Daigle">
<organization> </organization>
<address>
<email>ldaigle@thinkingcat.com</email>
</address>
</author>
<author role="editor" initials="O.M." surname="Kolkman" fullname="Olaf M. Kolkman">
<organization>Internet Society</organization>
<address>
<email>kolkman@isoc.org</email>
</address>
</author>
<author surname="Internet Architecture Board">
<organization abbrev="(IAB)">Internet Architecture Board</organization>
<address>
<email>iab@iab.org</email>
</address>
</author>
<date year="2016" month="February"/>
<abstract>
<t>
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. This document obsoletes RFC 5741, moving detailed content
to an IAB web page and preparing for more flexible output formats.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Previously RFCs (e.g. <xref target="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.
</t>
<t>
As the RFC Series has evolved over the years, there has been
increasing concern over appropriate labelling 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.
</t>
<t>
With the definition of the different RFC streams <xref
target="RFC4844"/>, it is appropriate to formalize the
definition of the various pieces of standard RFC boilerplate
and introduce some adjustments to ensure better clarity of
expression of document status, aligned with the review and
approval processes defined for each stream.
</t>
<t>
This memo identifies and describes the common elements of RFC
boilerplate structure. It describes the content required
for each kind of information. Details of exact textual and
layout requirements are left to a web page maintained by the
IAB, with due consultation with the community, for ease of
maintenance. This document obsoletes <xref
target="RFC5741"/>.
</t>
<t>
The changes introduced by this memo should be implemented as
soon as practically possible after the document has been
approved for publication.
</t>
<!-- The Introduction section -->
</section>
<section anchor="standards" title="RFC Streams and Internet Standards">
<t>
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.
</t>
<t>
The IETF is responsible for maintaining the Internet Standards
Process, which includes the requirements for developing,
reviewing and approving Standards Track and BCP RFCs. These,
and any other standards-related documents (Informational or
Experimental) are reviewed by appropriate IETF bodies and
published as part of the IETF Stream.
</t>
<t>
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.
</t>
<t>
Refer to <xref target="RFC2026"/>, <xref
target="RFC5742"/>, <xref target="RFC4844"/>, <xref
target="RFC6410"/>, and <xref target="RFC7127"/> and their
successors for current details of the IETF process and RFC
streams.
</t>
</section>
<section title="RFC Structural Elements">
<t>
This section describes the elements that are commonly found
in RFCs published today. This document specifies information that
is required in these publications. Exact specification of the
textual values required therein are provided by an IAB web page
</t>
<t>(URL to be provided during AUTH48).</t>
<t>As noted above, this web page is maintained by the IAB with
due consultation with the community. Following such
consultation, if the IAB decides to make any changes to this
material, the changes will be announced in a similar fashion to
other IAB statements.
Initial proposed text to be used in that web page is included in
<xref target="details"/>.
</t>
<section title="The title page header">
<t>
The information at the front of the RFC includes the
name and affiliation of the authors
as well as the RFC publication month and year.
</t>
<t>
There is a set of additional information that is needed
at the front of the RFC. Historically, this has been
presented with the information below in a left hand column,
and the author related information described above in the
right.
</t>
<t>
<list style="hanging">
<t hangText="<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 <xref
target='RFC0003'/>. Here, we obsolete the term "Network
Working Group" in order to indicate the originating
stream.
</t>
<t>
The <document source> is the name of the RFC
stream, as defined in <xref target="RFC4844"/> and its
successors. At the time of this publication, the
streams, and therefore the possible entries are:
<list style='symbols'>
<t>Internet Engineering Task Force</t>
<t>Internet Architecture Board</t>
<t>Internet Research Task Force</t>
<t>Independent Submission</t>
</list>
</t>
<t hangText="Request for Comments: <RFC number>">
This indicates the RFC number, assigned by the RFC
Editor upon publication of the document. This element
is unchanged.
</t>
<t hangText="<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 <xref target="RFC2026"/> and STDs <xref
target="RFC1311"/>.
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.
</t>
<t hangText="[<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"
<xref target="RFC7322"/>. Variants like "Obsoleted by"
are also used (e.g in <xref target="RFC5143"/>). Other
types of relationships may be defined by the RFC Editor
and may appear in future RFCs.
</t>
<t hangText="Category: <category>">
This indicates the initial RFC document category of the
publication. These are defined in <xref
target="RFC2026"/>. Currently, this is always one of:
Standards Track, Best Current Practice, Experimental,
Informational, or Historic. This element is unchanged.
</t>
</list>
</t>
<!-- Title Page Header section -->
</section>
<section anchor="Status" title="The Status of this Memo">
<t>
The "Status of This Memo" describes the category of the RFC,
including the distribution statement.
</t>
<t>
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-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.
</t>
</section>
<section title="Paragraph 1">
<t>
The first paragraph of the Status of this Memo section
contains a single sentence, clearly standing out. The
sentence will clearly identify the stream-specific status
of the document. The text to be used is defined by the
stream, with IAB and RFC Series Editor review for clarity.
</t>
</section>
<section title="Paragraph 2">
<t>
The second paragraph of the "Status of This Memo" will
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. The IAB defines a specific structure
defined to ensure there is clarity about review
processes and document types.
</t>
</section>
<section title="Paragraph 3">
<t>
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
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 <xref
target="I-D.rfc-editor-errata-process"/>. The exact wording
and URL is subject to change (at the RFC Editor's
discretion), but current text is:
</t>
<t>
"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/<static-path>/rfc<rfc-no>.html"
</t>
</section>
<section title="Noteworthy">
<t>
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 <xref
target="Structure"/>.
</t>
</section>
<!-- Status of This Memo section -->
</section>
<section title="Additional Notes">
<t>
Exceptionally, a review and publication process may
prescribe additional notes that will appear as labelled
notes after the "Status of This Memo".
</t>
<t>
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.
</t>
<!-- Additional Notes section -->
</section>
<section anchor="Structure" title="Other structural information in RFCs">
<t> 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
<xref target="RFC4844" />. These additions may or may not require
documentation in an RFC.
</t>
<t>
Currently the following structural information is available
or is being considered for inclusion in RFCs:
</t>
<t>
<list style='hanging'>
<t hangText="Copyright Notice">
A copyright notice with a reference to BCP78 <xref
target="BCP78"/> and an Intellectual Property statement
referring to BCP78 and BCP79 <xref target="BCP79"/>. The
content of these statements are defined by those BCPs.
</t>
<t hangText="ISSN">
The International Standard Serial Number <xref
target="ISO.3297.2007"/>: 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.
<!-- I stole that piece of text from
http://www.loc.gov/issn/issnbro.html -->
</t>
</list>
</t>
<!--Other structural information-->
</section>
<!-- Structural Elements section -->
<section title="Security considerations" >
<t>
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.
</t>
<!-- Security Considerations section -->
</section>
<section title="IANA considerations" >
<t>
None.
</t>
<!-- IANA consideration -->
</section>
<section title="RFC Editor Considerations" >
<t>
The RFC Editor is responsible for maintaining the consistency
of the RFC series. To that end the RFC Editor maintains a
style manual <xref target="RFC7322"/>. 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.
</t>
<t>
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.
</t>
<t>
[The rest of this section contains specific instructions towards
editing this document and can be removed before publication]
</t>
<t>
This section of the document needs to be removed before publication.
</t>
<t>
This memo introduces a number of modifications that will have
to be implemented in various tools, such as the xml2rfc tool,
the nit tracker and the rfc-erratum portal.
</t>
<t>
The number "XXXX" is to be replaced with RFC number of this
memo.
</t>
<t> In section <xref target="Structure"/>:
For the final publication, it should be warranted that the
ISSN is *not* split by a line break, for clarity.
</t>
<!-- RFC consideration -->
</section>
</middle>
<back>
<!-- <references title='Normative References'> </references>-->
<references title="Normative References">
<?rfc include="reference.RFC.2026" ?>
<?rfc include="reference.RFC.5742" ?>
</references>
<references title="Informative References">
<?rfc include="reference.ISO.3297.2007" ?>
<?rfc include="reference.RFC.0003" ?>
<!-- <?rfc include="reference.RFC.1150" ?> -->
<?rfc include="reference.RFC.1311" ?>
<?rfc include="reference.RFC.2629" ?>
<!-- <?rfc include="reference.RFC.3967" ?> -->
<?rfc include="reference.RFC.3979" ?>
<?rfc include="reference.RFC.4749" ?>
<?rfc include="reference.RFC.4844" ?>
<?rfc include="reference.RFC.5143" ?>
<?rfc include="reference.RFC.5378" ?>
<?rfc include="reference.RFC.5741" ?>
<?rfc include="reference.RFC.6410" ?>
<?rfc include="reference.RFC.7127" ?>
<?rfc include="reference.RFC.7322" ?>
<reference anchor='I-D.rfc-editor-errata-process'>
<front>
<title>RFC Editor Proposal for Handling RFC Errata</title>
<author initials='S' surname='Ginoza' fullname='Sandy Ginoza'>
<organization />
</author>
<author initials='A' surname='Hagens' fullname='Alice Hagens'>
<organization />
</author>
<author initials='R' surname='Braden' fullname='Robert Braden'>
<organization />
</author>
<date month='May' day='21' year='2008' />
<abstract><t>This document describes a web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the book-keeping for handling errata.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-rfc-editor-errata-process-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-rfc-editor-errata-process-02.txt' />
</reference>
<?rfc linefile="646:headers-boilerplates.xml"?>
<reference anchor="BCP78" >
<front>
<title>Rights Contributors Provide to the IETF Trust</title>
<author role="editor" initials="S." surname="Bradner">
<organization />
</author>
<author role="editor" initials="J." surname="Contreras">
<organization />
</author>
<date month='November' year="2008"/>
</front>
<seriesInfo name='BCP' value='78' />
<annotation>At the moment of publication:<xref target="RFC5378"/></annotation>
</reference>
<reference anchor="BCP79" >
<front>
<title>Intellectual Property Rights in IETF Technology</title>
<author role="editor" initials="S." surname="Bradner">
<organization />
</author>
<author role="editor" initials="T." surname="Narten">
<organization/>
</author>
<date month='April' year="2007"/>
</front>
<seriesInfo name='BCP' value='79' />
<annotation>At the moment of publication:<xref target="RFC3979"/>and<xref target="RFC4749"/></annotation>
</reference>
</references>
<section title="IAB members at time of approval">
<t>
The IAB members at the time this memo was approved
were (in alphabetical order):
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks to Bob Braden, Brian Carpenter, Steve Crocker, Sandy
Ginoza, and John Klensin who provided background information
and inspiration.
</t>
<t>Thanks to the members of the RFC Series Oversight Committee
(RSOC) for assistance and review: Alexey Melnikov, Nevil Brownlee,
Bob Hinden, Sarah Banks, Robert Sparks, Tony Hansen, and
Joe Hildebrand.
</t>
<t>Various people have made suggestions that improved the
document. Among them are: Lars Eggert, Alfred Hoenes, and Joe Touch.
</t>
<t>
This document was produced using the xml2rfc tool <xref
target="RFC2629"/>.
</t>
<!-- Acknowledgements section -->
</section>
<section anchor="details" title="Initial Formating Details">
<t>This section provides suggested starting text for the use of
the IAB in order to simplify populating the web page to be used
to maintain the list of required verbiage.
</t>
<section title="RFC Title Page Header">
<t>
An RFC title page header can be described as follows:
<figure>
<artwork>
------------------------------------------------------------------------
<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>
------------------------------------------------------------------------
</artwork>
</figure>
For example, a sample earlier RFC header is as follows:
<figure>
<artwork>
------------------------------------------------------------------------
Network Working Group T. Dierks
Request for Comments: 4346 Independent
Obsoletes: 2246 E. Rescorla
Category: Standards Track RTFM, Inc.
April 2006
------------------------------------------------------------------------
</artwork>
</figure>
</t>
</section>
<section title="Constructing a "Status of this Memo" Section">
<t>The following sections describe mandated text for use in
specific parts of the "Status of this Memo" portion of an RFC.
For convenience, the RFC Editor maintains example expansions of
all permutations of the paragraphs described in this document
(at the time of publication, at
http://www.rfc-editor.org/materials/status-memos.txt).
When in conflict, these following sections are authoritative.
</t>
<section title="First Paragraph">
<t>The following are the approved texts for use in the first
paragraph of the "Status of this Memo" portion of an RFC.
See RFCXXXX section 3.3.
<list style='hanging'>
<t hangText="For 'Standards Track' documents:" >
"This is an Internet Standards Track document."
</t>
<t hangText="For 'Best Current Practices' documents:" >
"This memo documents an Internet Best Current Practice."
</t>
<t hangText="For other categories" >
"This document is not an Internet Standards Track
specification; <it is published for other
purposes>."
</t>
</list>
For Informational, Experimental, Historic and future
categories of RFCs, the RFC editor will maintain an
appropriate text for <it is published for other
purposes>. Initial values are:
</t>
<t>
<list style='hanging'>
<t hangText="Informational: "> "it is published for informational purposes."
</t>
<t hangText="Historic: "> "it is published for the historical record."
</t>
<t hangText="Experimental: "> "it is published for examination,
experimental implementation, and evaluation."
</t>
</list>
</t>
</section>
<section title="Second Paragraph">
<t>See RFCXXXX section 3.4.</t>
<t>The second paragraph may include some text that is specific to the
initial document category, as follows:
when a document is Experimental or Historic the
second paragraph opens with:
</t>
<t>
<list style='hanging'>
<t hangText="Experimental:">
"This document defines an Experimental Protocol for the
Internet community."
</t>
<t hangText="Historic:">
"This document defines a Historic Document for the Internet
community."
</t>
</list>
</t>
<t>
The text that follows is stream dependent --
these are initial values and may be updated by stream definition document updates
and recorded by the IAB on the web page..
</t>
<t>
<list style='hanging'>
<t hangText="IETF Stream:">
"This document is a product of the Internet Engineering
Task Force (IETF)."
</t>
<t> If there has been an IETF consensus call per IETF
process, this additional text 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)."
</t>
<t hangText="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."
</t>
<t> If the document represents IAB consensus, this additional text
should be added:
"It represents the consensus of the Internet Architecture Board (IAB)."
</t>
<t hangText="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."
</t>
<t>
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 "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)".
</t>
<t hangText="Independent Submission 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.
</t>
</list>
</t>
<t>
For non-IETF stream documents a reference to <xref
target="standards"/> 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 <xref target="standards"/> of RFC XXXX."
</t>
<t>
For IETF stream documents a similar reference is added:
"Further information on [BCPs or Internet Standards] is
available in <xref target="standards"/> of RFC XXXX." for BCP
and Standard Track documents; "Not all documents approved by
the IESG are candidate for any level of Internet Standards;
see <xref target="standards"/> of RFC XXXX." for all other categories.
</t>
</section>
<section title="Third Paragraph">
<t>See RFCXXXX section 3.5.</t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:10:32 |