I-D Guidelines R. Housley (for the IESG)

I-D Guidelines R. Housley (for the IESG)
Vigil Security
7 December 2010

Guidelines to Authors of Internet-Drafts

Table of Contents

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
Appendix A. Change History
Author's Address

1. Submissions

ALL submissions to the Internet-Draft repository 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.

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 [RFC2026] 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.

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

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"

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:

1. All I-D filenames begin with "draft"

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

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

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

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

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 [5], 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

[IDST] <https://datatracker.ietf.org/idst/upload.cgi>

[INDEX] <http://www.ietf.org/id/1id-abstracts.txt>

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.

[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.

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

[RFCED] <http://www.rfc-editor.org/styleguide.html>

[TLP] <http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>

[TRACK] <https://datatracker.ietf.org/idtracker>

Appendix A. Change History

Changes from February 9, 2010 version to May 4, 2010 version:

o Updated the [RFCED] reference to point to the RFC Editor
Style Guide.

Changes from February 7, 2010 version to February 9, 2010 version:

o Correct the typographical errors in the excerpts from the
Trust License Policy (TLP) in Section 4.

Changes from February 2, 2010 version to February 7, 2010 version:

o New builerplate can push the table of contents to page three.

o Ask for a table of contents if the I-D exceeds 15 pages. Dropped
"about."

Changes from February 27, 2008 version to February 2, 2010 version:

o Update the references to reflect the current BCPs. Remove the
reference to rfc2333bis, which is no longer an active work item.
Add a references for the I-D Submission Tool and the Data Tracker.

o Rewrite of Section 3.

o Structure the choices in Section 4 to match the current BCPs.

o Provide two boilerplate options in Section 5, as approved by the
IESG on 7 January 2010.

o Remove the discussion of grace period from Section 7. With the
I-D Submission Tool, there is no longer a need for one.

o Include URLs that are not redirected.

o Significant editorial changes.

Changes from October 13, 2006 version to February 27, 2008 version:

o Add reference to I-D Submission Tool in Section 1.

o Add rule that -00 documents that are WG submissions that are
renaming of existing documents can be submitted up to the later
deadline in Section 7.

o Update references to [RFC4748] to reflect the RFC number.

o Update filename requirements to prevent sequential hyphens

Changes from March 25, 2005 version to October 13, 2006 version:

o Relax rules for "document source" part of filename in Section 7.

o Updated to reflect changes described in [RFC4748].

o Loosen the "near the end of the document" text for boilerplate in
Section 3.

o Changed idnits reference to tools.ietf.org

Changes from Feb 8, 2005 version to March 25, 2005 version:

o Update all references from RFCs 3667/3668 to 3978/3979.

o Update IPR boilerplate with words from RFC3978. Add a note that
it's not appropriate to change the boilerplate, even if it seems
wrong.

o Make it clear in the IPR section that the author is required to
disclose IPR under certain circumstances by the 3978/3979
boilerplate.

o Add "Any submission which does not include these statements will
be returned to the submitter. The IETF Secretariat will NOT add
this text." to the section on Internet-Draft boilerplate too.

o Spell out exactly how drafts are named.

o Remove the option of asking the secretariat for an Internet-Draft
name.

o Add the option for an author to un-expire or extend the expiration
date of an Internet-Draft.

o Treat Postscript and PDF the same.

o Say "254mm" instead of "10 inches" since we're talking about
metric paper sizes.

o Fix minor typos and make some wording changes in the section on
Abstracts, making the text closer to 2223bis.

o Include documentation on the I-D deadline and how to check on I-Ds
submitted near the deadline.

o Add a pointer to the RFC-Editor's formatting web page.

Author's Address

Russ Housley
Vigil Security
918 Spring Knoll Drive
Herndon, VA 20170
USA

Email: [email protected]