1. Submissions

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 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 Considerations

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.

3. IPR-Related Notices Required in Internet-Drafts

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.

4. Optional IPR-Related Notices that May Be Included in Internet-Drafts

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.

5. Internet-Draft Boilerplate

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."

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.

6. Formatting

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 ___@______ 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.

7. Naming and Submitting

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"

Document source:

Working Group: The string "ietf-" followed by the working group acronym.

Other: A string identifying an IETF-related body. The currently allowed list is

iab

iana

iaoc

iesg

ietf-edu

ietf-tools

ietf-trust

irtf

rfc-editor

rfced (Historic)

ietf-iesg (Historic)

ietf-proto (Historic)

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 "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. Expiring

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-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 Rights

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.

10. Further Reading

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.