|
Guidelines to Authors of Internet-Drafts
Table of Contents 1.
Submissions
1. SubmissionsALL 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 internet-drafts@ietf.org. 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.
2. General ConsiderationsThe 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.
3. IPR-Related Notices Required in Internet-Drafts BCP 78 [RFC5378] and BCP 79 [RFC3979][RFC4879]
require specific intellectual property rights (IPR) statements in every Internet-Draft. Documents that will be published as IETF stream RFCs must include the first choice, which is:
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:
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.
4. Optional IPR-Related Notices that May Be Included in Internet-DraftsIf 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:
The second choice is when the contributor does not intend for the I-D to be published as an RFC. The second choice is:
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.
5. Internet-Draft BoilerplateOne 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:
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:
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.
6. FormattingEvery 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:
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.
7. Naming and SubmittingAn Internet-Draft filename is made up of several components, each separated by a hyphen. No empty components are permitted. The components, in order are:
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 "internet-drafts@ietf.org" 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 ietf-action@ietf.org (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 ietf-action@ietf.org. 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 ietf-action@ietf.org (using the suggested subject line "Status of I-D Submission: <filename>") and include the acknowledgement for your document in the body.
8. ExpiringAn Internet-Draft will expire exactly 185 days from the date that it is posted on the IETF Web site (<http://www.ietf.org/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 internet-drafts@ietf.org (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 internet-drafts@ietf.org (using the suggested subject line "Extend expiration date for <filename>") and should be from an author, a working group chair, or an IESG member.
9. Intellectual Property RightsIf 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.
10. Further ReadingThis 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.ietf.org/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].
11. References
Appendix A. Change HistoryChanges 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:
Author's Address
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
