These guidelines aim to make it easier for authors to create and submit Internet-Drafts.
7 December 2010
2.? General Considerations
3.?IPR-Related Notices Required in Internet-Drafts
4.? Optional IPR-Related Notices that May Be Included in Internet-Drafts
5.? Internet-Draft Boilerplate
7.?Naming and Submitting
9.? Intellectual Property Rights
10.? Further Reading
Appendix?A.? Change History
§? Author's Address
ALL submissions to the Internet-Draft directories should use the I-D Submission tool [IDST].?
If you run into problems when submitting an Internet-Draft using the I-D Submission tool, or it is not available or you are offline, you may alternatively submit your draft by email to [email protected] However, be advised that manual processing always takes additional time.?
When using the email submission method, the I-D may be sent as an attachment to the message, or the message may contain a URL that points to a copy of the I-D stored on a server.?
Attachments must be plain text, PostScript, or PDF. These are the only formats that are currently supported for I-Ds, and any other attachment, such as a ZIP file, will be discarded without opening.
The Internet-Drafts repository is available to provide authors with the ability to distribute and solicit comments on documents they may eventually submit for publication as an RFC. I-Ds are not an archival document series. I-Ds should not be cited or quoted in any formal document, except as "work in progress". Unrevised documents placed in the I-D repository have a maximum life of 185 days. After that time, if I-D is not updated, it will be deleted. See RFC 2026 [RFC 2026] for more information. In exceptional circumstances, an extension of this lifetime is possible; see?Section 8?below. After a document becomes an RFC, it will be replaced in the I-D repository with an announcement of the RFC.
I-Ds are generally in the format of an RFC, although they may be rough drafts when the first version is submitted. This format is specified fully in "Instructions to RFC Authors" (on the RFC Editor's Web pages [RFCED]). In brief, an I-D must be submitted in ASCII text, and should be limited to 72 characters per line and 58 lines per page, and each page ends with a formfeed character. Overstriking to achieve bolding or underlining is not acceptable.
PostScript and/or PDF are acceptable, but only when submitted with a matching ASCII version (even if figures must be omitted). PostScript and PDF should be formatted for use on 8.5x11 inch paper. If A4 paper is used, an image area no greater than 254mm high should be used to avoid printing extra pages when printed on 8.5x11 paper.
There are differences between the RFC and I-D format. I-Ds are NOT RFCs, and I-Ds are NOT a numbered document series. The label "INTERNET-DRAFT" should appear in the upper left hand corner of the first page. If the I-D is associated with an IETF working group, the name of the working group should appear on the line below the "INTERNET-DRAFT" label. The document should NOT refer to itself as an RFC or a draft RFC.
The I-D should neither state nor imply that it has any standards status; to do so conflicts with the roles of the RFC Editor and the IESG. The title of the document should not imply a status. Avoid the use of the terms Standard, Proposed, Draft, Experimental, Historic, Required, Recommended, Elective, or Restricted in the I-D title. Indicating what intended status the I-D if it is published as an RFC is fine; however, this should be done with the words "Intended status: <status>" on the left side of the first page.
All I-Ds must include one of the following statements. They are normally placed on the first or second page the document.
Documents that will be published as IETF stream RFCs must include the first choice, which is:
"Copyright (c) YYYY 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 Simplified BSD License."
Documents that will be published as IAB, IRTF, or Independent Submission stream RFCs may include the second choice instead of the first choice copyright statement. The second choice is:
"Copyright (c) YYYY 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."
Of course, "YYYY" in either of the copyright statements should be replaced with the current year.
Any I-D submission which does not include one of these statements will be returned to the submitter. The IETF Secretariat will NOT add this text for the author.
Note that although these statements appear to be written in English, they are actually written in lawyerese. Although it is awfully tempting to modify them, please don't. It adds too much overhead to the I-D submission process to evaluate alterations to the boilerplate to decide whether or not it changes the meaning.
If the submitter desires to eliminate the IETF's right to make modifications and derivative works of an Internet-Draft, one of the following two notices may be included after the IPR statement. The first choice is used if the contributor intends for the I-D to be published as an RFC.?
The first choice is used if the contributor intends for the I-D to be published as an RFC. The first choice is:?
"This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English."?
The second choice is when the contributor does not intend for the I-D to be published as an RFC. The second choice is:?
"This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft."?
These notices may not be used with any IETF standards-track document or with most working group documents, except as discussed in BCP 78 [RFC5378], 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.
The first 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.?
The second 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.
One of the following verbatim statements must follow the IPR statement and optional notices if any are included. The first choice has been in use for a very long time, and it is still acceptable and appropriate. The first choice is:
"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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts.
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."
The list of current Internet-Drafts can be accessed at http://www.fj4o.com/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at http://www.fj4o.com/shadow.html"
In the modern Internet, the need for stable URLs is more important than providing multiple sites around the world to obtain I-Ds. Also, search engines have replaced the need for a file containing a collection of I-D abstracts. As a result, the second choice is:
"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 http://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.""
Any submission which does not include one of these statements will be returned to the submitter. The IETF Secretariat will NOT add this text for the author.
Every Internet-Draft must have an Abstract section. 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 section is used as a summary in publication announcements and in the online index of I-D [INDEX].
Composing a useful Abstract is a non-trivial 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 5-10 lines, but an Abstract of more than 20 lines or less than 3 lines is generally not acceptable.
An Abstract should be complete in itself, so it should contain no citations unless they are completely defined within the Abstract. Abbreviations appearing in the Abstract should generally be expanded in parentheses. There is a small set of reasonable exceptions to this rule; for example, readers don't need to be reminded of what "IP" or "TCP" or "MIB" means. In the end, therefore, this is a judgment call, but please err on the side of explicitness.
In addition, the I-D should contain a section giving name and contact information (postal mail, voice/fax number and/or e-mail) for the authors.
All I-D must contain the full filename (beginning with draft- and including the version number) in the text of the document. The filename information should, at a minimum, appear on the first page (possibly with the title). I-D filenames use ONLY lowercase characters. See Section 7 for more information on filenames.
It is strongly recommended that the draft include a notice (with email address) of where comments should be sent. For example:
"Comments are solicited and should be addressed to the working group's mailing list at [email protected]______ and/or the author(s)."
A document expiration date should appear on the first and last page of the I-D. The expiration date is 185 days following the I-D submission of the document. Use of the phrase "expires in six months" or "expires in 185 days" is not acceptable.
I-Ds must be in ASCII. No 8-bit characters are allowed. If you need to include code points, one suggestion is to use the Unicode convention: U+XXXX, where X is a hexadecimal digit.
If the I-D is longer than fifteen pages, please include a table of contents to make the document easier to reference. The table of contents should be included at the start of the document, after the Abstract, IPR-related notices, and other boilerplate.
An Internet-Draft filename is made up of several components, each separated by a hyphen. No empty components are permitted. The components, in order are:
All I-D filenames begin with "draft"
Working Group: The string "ietf-" followed by the working group acronym.
Other: A string identifying an IETF-related body. The currently allowed list is
Individual: A string related to the name of one of the authors in some way. There are no mechanical rules for this string but objectionable or misleading strings are subject to change or removal at the discretion of the Secretariat.
Document name. For non-working group documents that are targeted at a working group, this string often begins with the working group abbreviation. This document name is a word or two that reflect what the draft is about.
Two digit decimal version number; the initial draft uses "00".
Note that the limit on the total length of an I-D filename excluding the version number is 50 characters, and the only characters allowed in an I-D filename are lowercase letters, numerals and hyphens. Two sequential hyphens are not permitted. I-D filenames are never reused; if a previous document has used your desired I-D filename, then you must pick another one.
For those authors submitting updates to existing I-D, the choice of the I-D filename is easily determined; up the version by 1. For new documents, submit the document with a suggested I-D filename following the above rules. Note that if the suggested filename is not acceptable for some reason (e.g., not getting working group chair approval for a working group document), the document will have to be resubmitted with an acceptable I-D filename.
If the document is a new one (i.e., a version of "00") and is submitted as a working group document, the IETF Secretariat needs permission from one of the chair of the IETF working group to publish it. Working group chairs should submit this permission at (or close to) the time that the draft is submitted for posting. When the I-D Submission tool is not used, authors are encouraged to send the document to "[email protected]" and at the same time CC to the working group chair(s). If the document is accepted as a working group document, then it will have the draft-ietf-<wg acronym> I-D filename and will be announced on the working group mailing list by the IETF Secretariat. If the document is not accepted as a working group document, it will be processed as an individual submission, where the filename will be draft-<yourname>, as described above.
NOTE: Version numbers are based on the I-D filename (as in first, second, or third version of this document). If there is a I-D filename change, the version number starts over at -00. Put another way, the prior version number will NOT be incremented when an I-D filename has changed, e.g., from an individual to a working group document. ALL FILES BEGIN at -00.
Before each IETF meeting, a deadline is announced for submitting documents ahead of time to be published for discussion at the meeting. For new documents, the deadline is one week earlier than for revisions of existing drafts. The only exception is for version -00 working group drafts that replace existing non-working-group documents; these documents may be submitted up to the deadline for new versions of existing documents. Care should be taken when submitting an I-D near the deadline. The Secretariat receives hundreds of I-D immediately preceding an IETF meeting, and it can take several days to process and post them all, especially the ones that do not use the I-D Submission Tool [IDST]. If an I-D that was submitted very close to the deadline has not been posted and announced within three days, then the submitter should send a message to [email protected] (using the suggested subject line "Status of I-D Submission: <filename>") and reference the acknowledgement for the document in the body of the message. The Secretariat will happily investigate the situation and post any valid submission that was not posted in the first round.
When you submit an I-D, you will receive an acknowledgement message from the Secretariat. The subject and details are different for acknowledments from the I-D Submission Tool and submission by email. If you do not receive an acknowledgement within 2 business hours (in the Pacific time zone) after submitting your Internet-Draft, please contact the Secretariat by sending a message to [email protected]. The suggested subject line for this note is: "Status of I-D Submission: <filename>". If you need to track the status of your Internet-Draft at a later date, please send a message to [email protected] (using the suggested subject line "Status of I-D Submission: <filename>") and include the acknowledgement for your document in the body.
An Internet-Draft will expire exactly 185 days from the date that it is posted on the IETF Web site (<http://www.fj4o.com/id-info/>) unless it is replaced by an updated version (in which case the clock will start all over again for the new version, and the old version will be removed from the I-D repository), or unless it is under official review by the IESG (i.e., a request to publish it as an RFC has been submitted). Specifically, when an I-D enters the "Publication Requested" state in the Data Tracker [TRACK], it will not be expired until its status is resolved (e.g., it is published as an RFC). Data Tracker states not associated with a formal request to publish a document (e.g., "AD is Watching") will not prevent an I-D from expiring.
I-Ds will not expire during the period surrounding an IETF meeting when posting of updates to I-Ds is suspended (i.e., between the cutoff date for submission of updated I-Ds, which is usually two weeks prior to an IETF meeting, and the date that posting of I-Ds resumes). All I-Ds scheduled to expire during this period will expire on the day that the Secretariat once again begins posting I-Ds.
When an I-D expires, a "tombstone" file will be created that includes the filename and version number of the I-D that has expired. The filename of the tombstone file will be the same as that of the expired I-D with the version number increased by one. If a revised version of an expired I-D is submitted for posting, then the revised version will replace the tombstone file and must have the same version number as that previously assigned to the tombstone file. Tombstone files will never expire and will always be available for reference unless they are replaced by updated versions of the subject I-D or the expired version is brought back by the explicit action of an Area Director.
An expired I-D may be unexpired when necessary to further the work of the IETF, including IETF liaison with other standards bodies. Such action will be taken by request of an IESG member, a chair of the working group associated with the I-D, or one of the document authors. Such a request may be overridden; e.g., a chair of the working group associated with the I-D will be notified if an author requests unexpiration and may request that the action not occur. This request should be sent to [email protected] (using the suggested subject line "Resurrect I-D <filename>") and should come from an author, a working group chair, or an IESG member.
The expiration date of an unexpired I-D may be extended with the same rules as unexpiration. This request should be sent to [email protected] (using the suggested subject line "Extend expiration date for <filename>") and should be from an author, a working group chair, or an IESG member.
If you think that you, your company, or anyone else owns a patent or other IPR on the work described in the I-D, you should carefully read BCP 79 [RFC3979][RFC4879]. The first notice required in I-D, described in Section 3 of this document, obligates you to send an IPR disclosure statement under certain circumstances. Before submitting the I-D, it is advisable to talk to the working group chair or area directors about it.
This document is for helping authors. If you need the definitive rules, then read the following documents. The IETF Standards Process is described in RFC 2026 [RFC2026]. The IETF rules concerning copyright are described in BCP 78 [RFC5378]. The IETF rules on IPR are described in BCP 79 [RFC3979][RFC4879]. The IETF Trust Legal Provisions Relating to IETF Documents [TLP], called "the TLP" for short, provide many details about copyright policy and practice.
There are several tools to help the process of writing an I-D in this format; the RFC Editor has collected several pointers on their web page (<http://www.rfc-editor.org/formatting.html>).
Henrik Levkowetz has written an excellent tool that checks many of these requirements: <http://tools.ietf.org/tools/idnits/>.
The I-D Checklist <http://www.fj4o.com/id-info/checklist.html> is a good reference when submitting a document to the IESG for publication as an RFC.
Also, the RFC Editor's Web pages on how to publish an RFC will be useful [RFCED].
[RFC3979]?Bradner, S., "Intellectual Property Rights in IETF Technology," BCP?79, RFC?3979, March?2005 (TXT).
[RFC4879] Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979," BCP 79, RFC 4879, April 2007.
[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust," BCP 78, RFC 5378, November 2008.
Changes from February 9, 2010 version to May 4, 2010 version:?
Changes from February 7, 2010 version to February 9, 2010 version:
Changes from February 2, 2010 version to February 7, 2010 version:
Changes from February 27, 2008 version to February 2, 2010 version:
Changes from October 13, 2006 version to February 27, 2008 version:
Changes from March 25, 2005 version to October 13, 2006 version:
Changes from Feb 8, 2005 version to March 25, 2005 version: