All Internet-Drafts must contain the following sections:
For each of these sections, please consult the RFC Editor's Style Guide for further guidance.
Every Internet-Draft must have an abstract. The abstract should provide a concise and comprehensive overview of the purpose and contents of the entire document. Its purpose is to give a technically knowledgeable reader a general overview of the function of the document, to decide whether reading it will be useful. In addition to its function in the document, the abstract is used as a summary in publication announcements and in the online index of I-Ds.
Composing a useful abstract is a nontrivial writing task. Often, a satisfactory abstract can be constructed in part from material from the introduction section, but a good abstract will be shorter, less detailed, and broader in scope than the introduction. Simply copying and pasting the first few paragraphs of the introduction is tempting, but it generally results in an abstract that is both incomplete and redundant. An abstract will typically be around 50-150 words in length. An abstract that is much shorter or longer is generally not acceptable.
An abstract should be complete in itself, so it should not contain citations unless they are completely defined within the abstract. Abbreviations appearing in the abstract should follow the Abbreviations guidelines.
The text of this section consists of two parts:
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on DD MMMM YYYY.
This section is automatically generated for authors who submit their I-D in RFCXML. Authors of plaintext I-Ds must reproduce the text exactly.
Authors who submit their I-D in RFCXML must indicate which IPR text to use by providing one of a set of enumerated values to the ipr attribute of the <rfc> element, and the tooling generates the actual required text. Authors preparing plaintext submissions must carefully reproduce the text from TLP Section 6 that is most appropriate for their Internet-Draft.
The majority of IETF stream I-Ds specify one of the following values for the ipr attribute:
"trust200902" generates a notice from the text of section 6.b of the TLP.
"pre5378Trust200902" generates a notice from the text of sections 6.b and 6.c.iii of the TLP. See the TLP Modification of February 15, 2009 section of the Trust FAQ for more information on when to use this value.
Additional values of the ipr attribute are available that generate notices that limit modifications and derivative rights. These notices may not be used with any IETF Standards Track document or with most working group documents, except as discussed in BCP 78, since the IETF must retain change control over its documents and the ability to augment, clarify, and enhance the original contribution in accordance with the IETF Standards Process.
"noModificationTrust200902" generates a notice from the text of sections 6.b and 6.c.i of the TLP. This choice may be appropriate when republishing standards produced by a standards body other than the IETF, industry consortia, or companies. These are typically published as Informational RFCs and do not require that change control be ceded to the IETF. Documents of this type convey information for the Internet community.
"noDerivativesTrust200902" generates a notice from the text of sections 6.b and 6.c.ii of the TLP. This choice may be used on I-Ds that are intended to provide background information to educate and to facilitate discussions within IETF working groups but are not intended to be published as RFCs.
Any Internet-Draft submitted that does not include one of the required IPR boilerplate notices will be rejected. The IETF Secretariat cannot add this for the author.
If you think that you, your company, or anyone else owns a patent or other Intellectual Property Rights (IPR) on the work described in the I-D, you should carefully read BCP 79. The first notice required in an I-D, described earlier in this section, obligates you to send an IPR disclosure statement under certain circumstances. In particular, when preparing a document intended to be included in the IETF Stream, before submitting the I-D, discussing it with the working group chairs or Area Directors is advised.
Your I-D must include an Introduction section that (among other things) explains the motivation for the I-D and (if appropriate) describes the applicability of the document, e.g., whether it specifies a protocol, provides a discussion of some problem, is simply of interest to the Internet community, or provides a status report on some activity. The Introduction must call out any RFCs an I-D intends to obsolete or update This may result in some duplication of text between the Abstract and the Introduction; this is acceptable.
As noted in the Abstract and Introduction sections above, the Abstract and Introduction must call out any RFCs an I-D intends to obsolete or update. There should also be a section providing greater detail about the motivation and changes.
RFC 3552 describes current best practices about writing a Security Considerations section. This section is mandatory in all documents.
The text of this section must have a meaningful exploration of security issues raised by the proposal, which should include both risks and a description of solutions or workarounds. It is rare that technical work can legitimately make a claim like "This protocol introduces no security considerations," so it needs to be fairly obvious for that to be believable, or the document will be returned for further development. Procedural documents, however, more commonly can claim no added security risk.
Some other references that may be useful when crafting this section are:
The Internet Assigned Numbers Authority (IANA) provides global coordination of the DNS root, IP addressing, and many other Internet protocol resources for the IETF. The "IANA Considerations" section must be present in a document and enumerate any actions IANA must take upon publication of the document as an RFC.
For more specific guidelines regarding structure and content for writing IANA Considerations sections, please see RFC 8126 and the IANA Protocol Registration Procedures.
A references section must be present and split into normative and informative sections. The IESG has a Statement on Normative and Informative References.
Normative and informative references to non-IETF documents are permitted. However, it is best to minimize such normative references, because assessing their status when the IETF document advances on the standards track is very difficult. It is important to use the exact title, author name(s), organization and publication date. External specifications referenced by Internet-Standard-level Technical Specifications or Applicability Statements must be to open external standards, per RFC 2026.
A bare URI is not generally considered a stable reference. For web-only documents, adding a reference number, title , and/or an author will help make the reference more stable. See the RFC Editor's Style Guide for specific guidance about URIs in Internet-Drafts. Judgment can be used here; the stability of normative references is even more important than the stability of informative references.
Also note that normative references to I-Ds will cause the referencing document to wait in the RFC Editor queue for the referenced I-Ds to be published as RFCs. They may in some cases become a cluster of documents that will be published as RFCs simultaneously.
Note that if the I-D is eventually published as an RFC, this information will not be changeable. When possible, provide contact information that is expected to be stable over time.
Per RFC 7322:
The total number of authors or editors on the first page is generally limited to five individuals and their affiliations. If there is a request for more than five authors, the stream-approving body needs to consider if one or two editors should have primary responsibility for this document, with the other individuals listed in the Contributors or Acknowledgements section. There must be a direct correlation of authors and editors in the document header and the Authors' Addresses section. These are the individuals that must sign off on the document during the AUTH48 process and respond to inquiries, such as errata.