before you turn in an Internet Draft will help prevent the draft from
being rejected due to errors in form and formatting.
An I-D should have approximately the same format as an RFC. Contrary
to many people’s beliefs, an I-D does not need to look exactly like
an RFC, but if you can use the same formatting procedures used by the
RFC Editor when you create your I-Ds, it will simplify the RFC
Editor’s work when your draft is published as an RFC. [RFC2223],
"Instructions to RFC Authors", describes the nroff formatting used by
the RFC Editor. There is also a tool called "xml2rfc", available
from http://xml.resource.org/, that takes XML-formatted text and
turns it into a valid Internet Draft.
An Internet Draft can be either a Working Group draft or an
individual submission. Working Group drafts are usually reviewed by
the Working Group before being accepted as a WG item, although the
chairs have the final say.
If you’re interested in checking the status of a particular draft, or
can’t remember its exact name, or want to find out which drafts a WG
is working on, two handy tools are available. The "Internet Drafts
Database Interface", at
https://datatracker.ietf.org/public/idindex.cgi, lets you search for
a draft by author, Working Group, date, or filename. The "I-D
Tracker", at https://datatracker.ietf.org/public/pidtracker.cgi, is
especially useful for authors who want to track the progress of their
draft as it makes its way through the publication process.
There are some informal rules for Internet Draft naming that have
evolved over the years. Internet Drafts that revise existing RFCs
often have draft names with "bis" in them, meaning "again" or
"twice"; for example, a draft might be called "draft-someone-
rfc2345bis-00.txt".
8.3.1. Recommended Reading for Writers
Before you create the first draft of your Internet Draft, you should
read four documents:
o More important than just explaining formatting, [RFC2223] also
explains what needs to be in an Internet Draft before it can
become an RFC. This document describes all the sections and
notices that will need to be in your document, and it’s good to
have them there from the beginning so that readers aren’t
surprised when you put them in later versions.
o [BCP22], "Guide for Internet Standards Writers", provides tips
that will help you write a standard that leads to
interoperability. For instance, it explains how to choose the
right number of protocol options, how to respond to out-of-spec
behavior, and how to show state diagrams.
o The online "Guidelines to Authors of Internet Drafts",
http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date
information about the process for turning in Internet Drafts, as
well as the most current boilerplate information that has to be
included in each Internet Draft.
o When you think you are finished with the draft process and are
ready to request that the draft become an RFC, you should
definitely read "Checklist for Internet Drafts (I-Ds) Submitted
for RFC Publication", http://www.ietf.org/ID-Checklist.html, a
list of common issues that have been known to stop documents in
the IESG. In fact, you should probably read that document well
before you are finished, so that you don’t have to make a bunch of
last-minute changes.
Also, you should visit the IETF Tools web pages,
http://tools.ietf.org, where you’ll find pointers to other tools that
will automate some of your work for the IETF.
8.3.2. Filenames and Other Matters
When you’re ready to turn in your Internet Draft, send it to the
Internet Drafts administrator at mailto:internet-drafts@ietf.org.
There is a real person at the other end of this mail address, whose
job is to make sure you’ve included the minimum items you need for
the Internet Draft to be published. When you submit the first
version of the draft, you also tell the draft administrator your
proposed filename for the draft. If the draft is an official Working
Group product, the name will start with "draft-ietf-" followed by the
designation of the WG, followed by a descriptive word or two,
followed by "00.txt".
For example, a draft in the S/MIME WG about creating keys might be
named "draft-ietf-smime-keying-00.txt". If it’s not the product of a
Working Group, the name will start with "draft-" and the last name of
one of the authors followed by a descriptive word or two, followed by
"00.txt". For example, a draft that someone named Smith wrote might
be named "draft-smith-keying-00.txt". If a draft is an individual
submission but relates to a particular Working Group, authors
sometimes follow their name with the name of the Working Group, such
as "draft-smith-smime-keying-00.txt". You are welcome to suggest
names; however, it is up to the Internet Drafts administrator (and,
if it is an official WG draft, the WG chair) to come up with the
filename. If you follow the naming guidelines given at
http://www.ietf.org/ietf/1id-guidelines.txt, chances are quite good
that your suggested filename will be fine.
After the first edition of a draft, the number in the filename is
incremented; for instance, the second edition of the S/MIME draft
named above would be "draft-ietf-smime-keying-01.txt". Note that
there are cases where the filename changes after one or more
versions, such as when a personal effort is pulled into a Working
Group; when a draft has its filename changed, the number reverts to
-00. Be sure to let the Internet Drafts administrator know the
previous name of the draft when such a name change occurs so that the
databases can be kept accurate.
8.4. Standards-Track RFCs
The procedure for creating and advancing a standard is described in
[BCP9]. After an Internet Draft has been sufficiently discussed and
there is rough consensus that what it says would be a useful
standard, it is presented to the IESG for consideration. If the
draft is an official WG draft, the WG chair sends it to the
appropriate Area Director after it has gone through Working Group
last call. If the draft is an individual submission, the draft’s
author or editor submits it to the appropriate Area Director. BCP 9
also describes the appeals process for people who feel that a Working
Group chair, an AD, or the IESG has made the wrong decision in
considering the creation or advancement of a standard.
After the I-D is submitted to the IESG, the IESG announces an IETF-
wide last call. This helps get the attention of people who weren’t
following the progress of the draft, and it can sometimes cause
further changes to the draft. It is also a time when people in the
WG who feel that they weren’t heard can make their comments to
everyone. The IETF last call is two weeks for drafts coming from WGs
and four weeks for individual submissions.
If the IESG approves the draft to become an Internet standard, they
ask the RFC Editor to publish it as a Proposed standard. After it
has been a Proposed standard for at least six months, the RFC’s
author (or the appropriate WG chair) can ask for it to become a Draft
standard. Before that happens, however, someone needs to convince
the appropriate Area Director that there are at least two
independent, interoperable implementations of each part of the
standard. This is a good test of the usefulness of the standard as a
whole, as well as an excellent way to check if the standard was
really readable.
A few things typically happen at this point. First, it’s common to
find that some of the specifications in the standard need to be
reworded because one implementor thought they meant one thing whereas
another implementor thought they meant something else. Another
common occurrence is that none of the implementations actually tried
to implement a few of the features of the standard; these features
get removed not just because no one tested them but also because they
weren’t needed.
Don’t be surprised if a particular standard doesn’t progress from
Proposed to Draft. In fact, most of the standards in common use are
Proposed standards and never move forward. This may be because no
one took the time to try to get them to Draft, or some of the
normative references in the standard are still at Proposed standard,
or it may be that everyone found more important things to do.
A few years after a document has been a Draft standard, it can become
an Internet standard, also known as "full standard" (it can happen in
as little as four months, but this is rare). This doesn’t happen
often, and it is usually reserved for protocols that are absolutely
required for the Internet to function. The IESG goes over the
document with a fine-tooth comb and looks for evidence of widespread
deployment before making a Draft standard an Internet standard.
8.4.1. Telling It Like It Is -- Using MUST and SHOULD and MAY
Writing specifications that get implemented the way you want is a bit
of an art. You can keep the specification very short, with just a
list of requirements, but that tends to cause implementors to take
too much leeway. If you instead make the specification very wordy
with lots of suggestions, implementors tend to miss the requirements
(and often disagree with your suggestions anyway). An optimal
specification is somewhere in between.
One way to make it more likely that developers will create
interoperable implementations of standards is to be clear about
what’s being mandated in a specification. Early RFCs used all kinds
of expressions to explain what was needed, so implementors didn’t
always know which parts were suggestions and which were requirements.
As a result, standards writers in the IETF generally agreed to limit
their wording to a few specific words with a few specific meanings.
[STD3], "Requirements for Internet Hosts -- Application and Support",
written way back in 1989, had a short list of words that had appeared
to be useful, namely, "must", "should", and "may". These definitions
were updated and further refined in [BCP14], "Key words for use in
RFCs to Indicate Requirement Levels", which is widely referenced in
current Internet standards. BCP 14 also specifically defines "must
not" and "should not", and it lists a few synonyms for the words
defined.
In a standard, in order to make it clear that you’re using the
definitions from BCP 14, you should do two things. First, refer to
BCP 14 (although most people refer to it as RFC 2119, because that’s
what BCP 14 tells you to do), so that the reader knows how you’re
defining your words. Second, you should point out which instances of
the words you are using come from BCP 14. The accepted practice for
this is to capitalize the words. That is why you see "MUST" and
"SHOULD" capitalized in IETF standards.
BCP 14 is a short document, and it should be read by everyone who is
reading or writing IETF standards. Although the definitions of
"must" and "must not" are fairly clear, the definitions of "should"
and "should not" cause a great deal of discussion in many WGs. When
reviewing an Internet Draft, the question is often raised, "Should
that sentence have a MUST or a SHOULD in it?" This is, indeed, a
very good question, because specifications shouldn’t have gratuitous
MUSTs, but also should not have SHOULDs where a MUST is needed for
interoperability. This goes to the crux of the question of over-
specifying and under-specifying requirements in standards.
8.4.2. Normative References in Standards
One aspect of writing IETF standards that trips up many novices (and
quite a few long-time IETF folks) is the rule about how to make
"normative references" to non-IETF documents or to other RFCs in a
standard. A normative reference is a reference to a document that
must be followed in order to implement the standard. A non-normative
reference (sometimes called an "informative reference") is one that
is helpful to an implementor but is not needed.
An IETF standard may make a normative reference to any other
standards-track RFC that is at the same standards level or higher, or
to any "open standard" that has been developed outside the IETF. The
"same level or higher" rule means that before a standard can move
from Proposed to Draft, all of the RFCs for which there is a
normative reference must also be at Draft or Internet standard. This
rule gives implementors assurance that everything in a Draft standard
or Internet standard is quite stable, even the things referenced
outside the standard. This can also delay the publication of the
Draft or Internet standard by many months (sometimes even years)
while the other documents catch up.
There is no hard-and-fast rule about what is an "open standard", but
generally this means a stable standard that anyone can get a copy of
(although they might have to pay for it) and that was made by a
generally recognized standards group. If the external standard
changes, you have to reference the particular instantiation of that
standard in your specification, as with a designation of the date of
the standard. Some external standards bodies don’t make old
standards available, which is a problem for IETF standards that need
to be used in the future. When in doubt, a draft author should ask
the WG chair or appropriate Area Director if a particular external
standard can be used in an IETF standard.
8.4.3. IANA Considerations
More and more IETF standards require the registration of various
protocol parameters, such as named options in the protocol. As we
noted in Section 3.2.4, the main registry for all IETF standards has
long been IANA. Because of the large and diverse kinds of registries
that standards require, IANA needs to have specific information about
how to register parameters, what not to register, who (if anyone)
will decide what is to be registered, and so on.
Anyone writing an Internet standard that may need a new IANA registry
or new values in a current IANA registry needs to read [BCP26],
"Guidelines for Writing an IANA Considerations Section in RFCs",
which describes how RFC authors should properly ask for IANA to start
or take over a registry. IANA also maintains registries that were
started long before BCP 26 was produced.
8.4.4. Security Considerations
One thing that’s required in every RFC and Internet Draft is a
"Security Considerations" section. This section should describe any
known vulnerabilities of the protocol, possible threats, and
mechanisms or strategies to address them. Don’t gloss over this
section -- in particular, don’t say, "Here’s our protocol, if you
want security, just use IPsec". This won’t do at all, because it
doesn’t answer the question of how IPsec interacts with your
protocol, and vice versa. Be sure to check with your Working Group
chair if you’re not sure how to handle this section in your draft.
See [BCP72], "Guidelines for Writing RFC Text on Security
Considerations", for more information on writing good security
considerations sections.
8.4.5. Patents in IETF Standards
The problems of intellectual property have cropped up more and more
often in the past few years, particularly with respect to patents.
The goal of the IETF is to have its standards widely used and
validated in the marketplace. If creating a product that uses a
standard requires getting a license for a patent, people are less
likely to implement the standard. Not surprisingly, then, the
general rule has been "use good non-patented technology where
possible".
Of course, this isn’t always possible. Sometimes patents appear
after a standard has been established. Sometimes there’s a patent on
something that is so valuable that there isn’t a non-patented
equivalent. Sometimes the patent holder is generous and promises to
give all implementors of a standard a royalty-free license to the
patent, thereby making it almost as easy to implement as it would
have been if no patent existed.
The IETF’s methods for dealing with patents in standards are a
subject of much debate. The official rules for all intellectual
property rights (IRP) in IETF documents (not just patents) are
covered in [BCP78] and [BCP79], "Intellectual Property Rights in IETF
Technology". Everyone who participates in IETF Working Groups will
probably find these documents interesting because they lay out the
rules that everyone agrees to follow.
Patent holders who freely allow their patents to be used by people
implementing IETF standards often get a great deal of goodwill from
the folks in the IETF. Such generosity is more common than you might
think. For example, RFC 1822 is a license from IBM for one of its
security patents, and the security community has responded very
favorably to IBM for this (whereas a number of other companies have
made themselves pariahs for their intractability on their security
patents).
If you are writing an Internet Draft and you know of a patent that
applies to the technology you’re writing about, don’t list the patent
in the document. Instead, consult the IETF IPR Disclosure Page
linked off the main IETF web site to determine how to proceed.
Intellectual property rights aren’t mentioned in RFCs because RFCs
never change after they are published, but knowledge of IPR can
change at any time. Therefore, an IPR list in an RFC could be
incomplete and mislead the reader. [BCP9] provides specific text
that should be added to RFCs where the author knows of IPR issues.
8.5. Informational and Experimental RFCs
As we noted earlier, not all RFCs are standards. In fact, plenty of
important RFCs are not on the standards track at all. Currently,
there are two designations for RFCs that are not meant to be
standards: Informational, like the Tao, and Experimental. (There is
actually a third designation, Historic, but that is reserved for
documents that were on the standards track and have been removed due
to lack of current use, or that more recent thinking indicates the
technology is actually harmful to the Internet.)
The role of Informational RFCs is often debated in the IETF. Many
people like having them, particularly for specifications that were
created outside the IETF but are referenced by IETF documents. They
are also useful for specifications that are the precursors for work
being done by IETF Working Groups. On the other hand, some people
refer to Informational RFCs as "standards" even though the RFCs are
not standards, usually to fool the gullible public about something
that the person is selling or supporting. When this happens, the
debate about Informational RFCs is renewed.
Experimental RFCs are for specifications that may be interesting, but
for which it is unclear if there will be much interest in
implementing them, or whether they will work once deployed. That is,
a specification might solve a problem, but if it is not clear that
many people think that the problem is important, or think that they
will bother fixing the problem with the specification, the
specification might be labeled an Experimental RFC. If, later, the
specification becomes popular (or proves that it works well), it can
be re-issued as a standards-track RFC. Experimental RFCs are also
used to get people to experiment with a technology that looks like it
might be standards-track material, but for which there are still
unanswered questions.
The IESG has created guidelines on how it chooses between
Informational and Experimental status:
http://www.ietf.org/u/ietfchair/info-exp.html. If you are creating a
document that you think might become an Experimental RFC, knowing the
current thinking will help you justify your proposed choice.
9. How to Contribute to the IETF
9.1. What You Can Do
*Read* -- Review the Internet Drafts in your area of expertise and
comment on them in the Working Groups. Participate in the discussion
in a friendly, helpful fashion, with the goal being the best Internet
standards possible. Listen much more than you speak. If you
disagree, debate the technical issues: never attack the people.
*Implement* -- Write programs that use the current Internet
standards. The standards aren’t worth much unless they are available
to Internet users. Implement even the "minor" standards, since they
will become less minor if they appear in more software. Report any
problems you find with the standards to the appropriate Working Group
so that the standard can be clarified in later revisions. One of the
oft-quoted tenets of the IETF is "running code wins", so you can help
support the standards you want to become more widespread by creating
more running code.
*Write* -- Edit or co-author Internet Drafts in your area of
expertise. Do this for the benefit of the Internet community, not to
get your name (or, even worse, your company’s name) on a document.
Draft authors are subject to all kinds of technical (and sometimes
personal) criticism; receive it with equanimity and use it to improve
your draft in order to produce the best and most interoperable
standard.
9.2. What Your Company Can Do
*Share* -- Avoid proprietary standards. If you are an implementor,
exhibit a strong preference for IETF standards. If the IETF
standards aren’t as good as the proprietary standards, work to make
the IETF standards better. If you’re a purchaser, avoid products
that use proprietary standards that compete with the open standards
of the IETF and tell the companies you buy from that you are doing
so.
*Open Up* -- If your company controls a patent that is used in an
IETF standard, convince the company to make the patent available at
no cost to everyone who is implementing the standard. In the past
few years, patents have caused a lot of serious problems for Internet
standards because they prevent some companies from being able to
freely implement the standards. Fortunately, many companies have
generously offered unlimited licenses for particular patents in order
to help the IETF standards flourish. These companies are usually
rewarded with positive publicity for the fact that they are not as
greedy or short-sighted as other patent-holders.
*Join* -- Become a member of ISOC. More important, urge any company
that has benefited from the Internet to become a corporate member of
ISOC, since this has the greatest financial benefit for the group.
It will, of course, also benefit the Internet as a whole.
10. IETF and the Outside World
10.1. IETF and Other Standards Groups
As much as many IETF participants would like to think otherwise, the
IETF does not exist in a standards vacuum. There are many (perhaps
too many) other standards organizations whose decisions affect the
Internet. There are also a fair number of standards bodies that
ignored the Internet for a long time and now want to get a piece of
the action.
In general, the IETF tries to have cordial relationships with other
significant standards bodies. This isn’t always easy, since many
other bodies have very different structures than the IETF does, and
the IETF is mostly run by volunteers who would probably prefer to
write standards rather than meet with representatives from other
bodies. Even so, some other standards bodies make a great effort to
interact well with the IETF despite the obvious cultural differences.
At the time of this writing, the IETF has some liaisons with large
standards bodies, including the ITU (International Telecommunication
Union), the W3C, the Unicode Consortium, and ISO/IEC JTC1 (Joint
Technical Committee of the International Organization for
Standardization and International Electrotechnical Commission). As
stated in the IAB Charter [BCP39], "Liaisons are kept as informal as
possible and must be of demonstrable value in improving the quality
of IETF specifications". In practice, the IETF prefers liaisons to
take place directly at Working Group level, with formal relationships
and liaison documents in a backup role.
Some of these liaison tasks fall to the IESG, whereas others fall to
the IAB. Detail-oriented readers will learn much about the formal
methods for dealing with other standards bodies in [BCP102], "IAB