| TOC |
|
1.
Submissions
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
6.
Formatting
7.
Naming and Submitting
8.
Expiring
9.
Intellectual Property Rights
10.
Further Reading
11.
References
§
Author's Address
A.
Change History
| TOC |
ALL submissions to the Internet-Draft directories must be sent to internet-drafts@ietf.org.
The Internet-Draft may be sent as an attachment to the email, or the email may contain a URL which points to a copy of the Internet-Draft stored on a server.
DO NOT SEND ZIP files. We will not open them.
| TOC |
The Internet-Drafts directories are available to provide authors with the ability to distribute and solicit comments on documents they may eventually submit to the IESG or RFC Editor for publication as an RFC. Internet-Drafts are not an archival document series. These documents should not be cited or quoted in any formal document. Unrevised documents placed in the Internet-Drafts directories have a maximum life of 185 days. After that time, they must be updated, or they will be deleted. See RFC 2026 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.)[RFC2026] for more information. In exceptional circumstances, an extension of this lifetime is possible; see Section 8 (Expiring) below. After a document becomes an RFC, it will be replaced in the Internet-Drafts directories with an announcement to that effect.
Internet-Drafts 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" (see the RFC Editor's Web pages and [I-D.rfc-editor-rfc2223bis] (Reynolds, J. and R. Braden, “Instructions to Request for Comments (RFC) Authors,” July 2004.)). In brief, an Internet-Draft must be submitted in ASCII text, and should be limited to 72 characters per line and 58 lines per page, followed by 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 deleted). 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 Internet-Draft format. Internet-Drafts are NOT RFCs and are NOT a numbered document series. The words "INTERNET-DRAFT" should appear in the upper left hand corner of the first page. The document should NOT refer to itself as an RFC or a draft RFC.
The Internet-Draft should neither state nor imply that it has any standards status; to do so conflicts with the role 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 title of the Internet-Draft. Indicating what status the document is aimed for is OK, but should be done with the words "Intended status: <status>".
| TOC |
All Internet-Drafts must have the following intellectual property rights (IPR) statement on the first page:
"By submitting this Internet-Draft, each author represents that any
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 aware will
be disclosed, in accordance with Section 6 of BCP 79."
(See RFC 3978 (Bradner, S., “IETF Rights in Contributions,” March 2005.)[RFC3978] section 5.1.)
All Internet-Drafts must include the following statements near the end of the document:
"Copyright (C) The Internet Society (YYYY).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth therein, the
authors retain all their rights."
"This
document and the information contained herein are provided on an "AS IS"
basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
(See RFC 3978 (Bradner, S., “IETF Rights in Contributions,” March 2005.)[RFC3978] sections 5.4 and 5.5.) "YYYY" in the copyright statement should be replaced with the current year.
Any submission which does not include these statements will be returned to the submitter. The IETF Secretariat will NOT add this text.
Note that although these statements appear to be written in English, they are actually written in lawyerese. Although it's awfully tempting to modify them, e.g., to remove "or she" in a document that has only male authors, please don't. It adds too much overhead to the Internet-Draft submission process to evaluate any given boilerplate variation to decide whether or not it changes the meaning.
| TOC |
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:
- a
- "This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English."
- b
- "This document may not be modified, and derivative works of it may not be created."
In the cases of MIB or PIB modules and in other cases where the Contribution includes material that is meant to be extracted in order to be used, the following should be appended to the above statements:
"other than to extract section XX as-is for separate use."
Statement (a) is used if the contributor intends for the Internet-Draft to be published as an RFC. Statement (b) is used along with the publication limitation statement below when the contributor does not intend for the Internet-Draft to be published as an RFC.
These notices may not be used with any standards-track document or with most working group documents, except as discussed in RFC 3978 (Bradner, S., “IETF Rights in Contributions,” March 2005.)[RFC3978] section 7.3, 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.
Statement (a) may be appropriate when republishing standards produced by other (non-IETF) standards organizations, industry consortia or companies. These are typically published as Informational RFCs, and do not require that change control be ceded to the IETF. Basically, documents of this type convey information for the Internet community. (See RFC 3978 (Bradner, S., “IETF Rights in Contributions,” March 2005.)[RFC3978] sections 5.2 and 7.3.)
If the Contributor only wants the contribution to be made available in an Internet-Draft (i.e., does not want the Internet-Draft to be published as an RFC) then the contributor may include the following publication limitation statement after Statement (b):
"This document may only be posted in an Internet-Draft."
This notice can be used on Internet-Drafts 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 an RFCs. (See RFC 3978 (Bradner, S., “IETF Rights in Contributions,” March 2005.)[RFC3978] section 5.3.)
| TOC |
The following verbatim statement must follow the IPR statement and optional notices (if any):
"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.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html"
Any submission which does not include these statements will be returned to the submitter. The IETF Secretariat will NOT add this text.
| TOC |
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 Internet-Drafts.
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 Internet-Draft should contain a section giving name and contact information (postal mail, voice/fax number and/or e-mail) for the authors.
All Internet-Drafts 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). Internet-Draft filenames use lowercase characters ONLY. See Section 7 (Naming and Submitting) 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 ___@______ and/or the author(s)."
A document expiration date should appear on the first and last page of the Internet-Draft. The expiration date is 185 following the submission of the document as an Internet-Draft. Use of the phrase "expires in six months" or "expires in 185 days" is not acceptable.
Internet-Drafts must be in ASCII. No 8-bit characters are currently allowed. If you need to include code points, a suggestion might be to use the unicode convention: U+XXXX, where X is a hexadecimal digit.
If the Internet-Draft is longer than about 15 pages, please include, on the second page, a table of contents to make the document easier to reference.
| TOC |
Internet-Draft filenames have four parts, separated with hyphens and which may themselves contain hyphens:
- Individual
- The name of the submitter (one of the authors). This can be a surname, a given name, or an email address used by an author, as specified in the Authors' Addresses section of the draft.
- Working Group
- The string "ietf-" followed by the working group acronym.
- Other
- A string identifying an IETF-related body, such as "iab", "iesg", "rfc-editor".
Note that although other variations of "Other" have been used in the past which have no direct relationship with one of the authors (most famously, "ymbk"), these are no longer permitted. Company and organization names are also not permitted.
Note that the limit on the total length of a filename excluding the version number is 50 characters, and the only characters allowed in a filename are lowercase letters, numerals and hyphens. Internet-Draft filenames are never reused; if a previous document has used your desired filename you must pick another.
For those authors submitting updates to existing Internet-Drafts, the choice of the file name is easily determined (up the version by 1). For new documents, submit the document with a suggested 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 the actual file name.
If the document is a new one (i.e., starting with revision -00.txt) and is submitted as a working group document, the IETF Secretariat needs permission from the chair(s) of the wg to publish it as a working group document. Working group chairs should submit this permission at (or close to) the time that the draft is submitted for posting. To expedite the process, authors are encouraged to send the document to "internet-drafts@ietf.org" and at the same time cc: to the chair(s) of the working group. If the document is accepted as a working group document, then it will have the draft-ietf-<working group acronym> file name 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: Revision numbers are based on the filename (as in first, second, or third version of this document). If there is a filename change, the version number starts over at -00. Put another way, the prior version number will NOT be incremented when an Internet-Draft 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 the meeting. For new documents, the deadline is one week earlier than for new versions of old drafts. Care should be taken when submitting an Internet-Draft near the deadline. The Secretariat includes a "grace period" after the cutoff time; while the auto response message changes right at the cutoff time, submissions that are received by the Secretariat during the grace period will still be posted. This grace period is normally more than sufficient to ensure that documents submitted close to the deadline are received and accepted for posting. The Secretariat receives hundreds of Internet-Drafts immediately preceding an IETF meeting, and it can take several days to process and post them all. If an Internet-Draft 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 auto-response acknowledgement for the document in the body of the message. The Secretariat will be happy to investigate the situation and post any valid submission that was not posted in the first round.
When you submit an Internet-Draft, you will receive an auto-response message from the Secretariat acknowledging that your Internet-Draft has been received. The subject line of the message will read: [Auto Response] <subject of your original message>. If you do not receive an acknowledgement within 2 hours after submitting your Internet-Draft, then please contact the Secretariat by sending a note 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, then please send a note to "ietf-action@ietf.org" (using the suggested subject line "Status of I-D Submission: <filename>") and include the auto-response acknowledgement for your document in the body.
| TOC |
An Internet-Draft will expire exactly 185 days from the date that it is posted on the IETF Web site (<http://www.ietf.org/ID.html>) 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 Internet-Draft directories), or unless it is under official review by the IESG (i.e., a request to publish it has been submitted). Specifically, when an Internet-Draft enters the "Publication Requested" state in the I-D Tracker, it will not be expired until its status is resolved (e.g., it is published as an RFC). I-D Tracker states not associated with a formal request to publish a document (e.g., "AD is Watching") will not prevent an Internet-Draft from expiring after 185 days.
Internet-Drafts will not expire during the period surrounding an IETF meeting when posting of updates to Internet-Drafts is suspended (i.e., between the cutoff date for submission of updated drafts, which is two weeks prior to an IETF meeting, and the date that posting of Internet-Drafts resumes). All Internet-Drafts scheduled to expire during this period will expire on the day that the Secretariat once again begins posting Internet-Drafts.
When an Internet-Draft expires, a "tombstone" file will be created that includes the filename and version number of the Internet-Draft that has expired. The filename of the tombstone file will be the same as that of the expired Internet-Draft with the version number increased by one. If a revised version of an expired Internet-Draft 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 Internet-Drafts.
An expired Internet-Draft may be unexpired when necessary to further the IETF's work, including IETF liaison with other standards bodies. Such action will be taken by request of an IESG member, a working group chair of the Internet-Draft's working group, or one of the document authors. Such a request may be overridden; e.g., a working group chair of the Internet-Draft's working group 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 be from an author, a working group chair or an IESG member.
The expiration date of an unexpired Internet-Draft 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.
| TOC |
If you think that you, your company, or anyone else owns a patent or other IPR on the work described in the draft, you should read carefully RFC 3979 (Bradner, S., “Intellectual Property Rights in IETF Technology,” March 2005.)[RFC3979]. The first notice required in Internet-Drafts, described in Section 3 (IPR-Related Notices Required in Internet-Drafts) of this document, obligates you to send an IPR disclosure under certain circumstances. Before submitting the draft, it would be a good advice to talk to the working group chair or area directors about it.
| TOC |
The IETF process is described in RFC 2026 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.)[RFC2026]. The IETF rules concerning copyright are described in RFC 3978 (Bradner, S., “IETF Rights in Contributions,” March 2005.)[RFC3978]. The IETF rules on IPR are described in RFC 3979 (Bradner, S., “Intellectual Property Rights in IETF Technology,” March 2005.)[RFC3979]. RFC 3978 and 3979 are updates to RFC 2026 and obsolete section 10 of that document. This document is for helping authors. If you need the definitive rules, read RFC 2026, RFC 3978 and RFC 3979.
More good references when submitting a document to the IESG for publication as an RFC are the web page on Submitting Internet-Drafts to the IESG (<http://www.ietf.org/ID-Checklist.html>), the RFC Editor's Web pages on how to publish an RFC (<http://www.rfc-editor.org/howtopub.html>), and the Instructions to RFC Authors ([I-D.rfc-editor-rfc2223bis] (Reynolds, J. and R. Braden, “Instructions to Request for Comments (RFC) Authors,” July 2004.)). Henrik Levkowetz has written an excellent tool that checks many of these requirements; it is available at <http://ietf.levkowetz.com/tools/idnits/>.
There are several tools to help the process of writing an Internet-Draft in this format; the RFC Editor has collected several pointers on their web page (<http://www.rfc-editor.org/formatting.html>).
| TOC |
| [I-D.rfc-editor-rfc2223bis] | Reynolds, J. and R. Braden, “Instructions to Request for Comments (RFC) Authors,” draft-rfc-editor-rfc2223bis-08 (work in progress), July 2004. |
| [RFC2026] | Bradner, S., “The Internet Standards Process -- Revision 3,” BCP 9, RFC 2026, October 1996. |
| [RFC3978] | Bradner, S., “IETF Rights in Contributions,” BCP 78, RFC 3978, March 2005. |
| [RFC3979] | Bradner, S., “Intellectual Property Rights in IETF Technology,” BCP 79, RFC 3979, March 2005. |
| TOC |
| Bill Fenner (for the IESG) | |
| AT&T Labs - Research | |
| 75 Willow Rd. | |
| Menlo Park, CA 94025 | |
| USA | |
| Email: | fenner@research.att.com |
| TOC |
Changes from Feb 8, 2005 version to March 25, 2005 version: