you're looking for, send a message to the list's "-request" address
(not to the list itself!).
3.5 Interim Working Group Meetings
Working groups sometimes hold interim meetings between IETFs.
Interim meetings aren't a substitute for IETF meetings, however -- a
group can't decide to skip a meeting in a location they're not fond
of and meet in Cancun three weeks later, for example. Interim
meetings require AD approval, and need to be announced at least one
month in advance. Location and timing need to allow fair access for
all participants. Like regular IETF meetings, someone needs to take
notes and send them to minutes@ietf.org, and the group needs to take
attendance.
4. BOFs
In order to form a Working Group, you need a charter and someone who
is able to be chair. In order to get those things, you need to get
people interested so that they can help focus the charter and
convince an Area Director that the project is worthwhile. A face-
to-face meeting is useful for this. In fact, very few WGs get
started by an Area Director; most start after a face-to-face BOF
because attendees have expressed interest in the topic.
A BOF meeting has to be approved by the Area Director in the relevant
area before it can be scheduled. If you think you really need a new
WG, approach an AD informally with your proposal and see what they
think. The next step is to request a meeting slot at the next face-
to-face meeting. Of course, you don't need to wait for that meeting
to get some work done, such as setting up a mailing list and starting
to discuss a charter.
BOF meetings have a very different tone than WG meetings. The
purpose of a BOF is to make sure that a good charter with good
milestones can be created, and that there are enough people willing
to do the work needed in order to create standards. Some BOFs have
Internet Drafts already in process, while others start from scratch.
An advantage of having a draft before the BOF is to help focus the
discussion. On the other hand, having a draft might tend to limit
what the other folks in the BOF want to do in the charter. It's
important to remember that most BOFs are held in order to get support
for an eventual Working Group, not to get support for a particular
document.
Many BOFs don't turn into WGs for a variety of reasons. A common
problem is that not enough people can agree on a focus for the work.
Another typical reason is that the work wouldn't end up being a
standard -- if, for example, the document authors don't really want
to relinquish change control to a WG. (We'll discuss change control
later in this document.) Only two meetings of a BOF can be scheduled
on a particular subject; either a WG has to form, or the topic should
be dropped.
5. ** New to the IETF? STOP HERE! (Temporarily) **
-----------------------------------------
If you're new to the IETF and this is the only reference you plan to
read before coming to the meeting, stop here -- at least temporarily.
Then, on your flight home, read the rest of the Tao. By that time
you'll be ready to get actively involved in the Working Groups that
interested you at the meeting, and the Tao will get you started on
your way.
6. RFCs and Internet Drafts
If you're a new IETF participant and are looking for a particular RFC
or Internet Draft, go to the RFCEditor's Web pages, http://www.rfc-
editor.org/rfc.html. That site also has links to other RFC
collections, many with search capabilities. If you know the number
of the RFCyou're looking for, go to the IETF RFCpages,
http://www.ietf.org/rfc.html. For Internet Drafts, the best resource
is the IETF web site, http://www.ietf.org/ID.html, where you can
search by title and keyword.
6.1 Getting a Standard Published
One of the most common questions seasoned IETFers hear from newcomers
is, "How do I get an IETF standard published?" A much better
question is, "Should I write an IETF standard?" since the answer is
not always "yes." If you do decide to try to write a document that
becomes an IETF standard, be warned that the overall process may be
arduous, even if the individual steps are fairly straightforward.
Lots of people get through the process unscathed, though, and there's
plenty of written guidance that helps authors emerge with their ego
more or less intact.
Every IETF standard is published as an RFC(a "Request For Comments,"
but everyone just calls them RFCs), and every RFCstarts out as an
Internet Draft (often called an "I-D"). The basic steps for getting
something published as an IETF standard are:
1. Publish the document as an Internet Draft
2. Receive comments on the draft
3. Edit your draft based on the comments
4. Repeat steps 1 through 3 a few times
5. Ask an Area Director to take the draft to the IESG (if it's an
individual submission). If the draft is an official Working
Group product, the WG chair asks the AD to take it to the IESG.
6. Make any changes deemed necessary by the IESG (this might
include giving up on becoming a standard)
7. Wait for the document to be published by the RFCEditor
A much more complete explanation of these steps is contained in BCP
9, "The Internet Standards Process." Anyone who writes a draft that
they hope will become an IETF standard must read BCP 9 so that they
can follow the path of their document through the process. BCP 9
goes into great detail on a topic that is very often misunderstood,
even by seasoned IETF participants: different types of RFCs go
through different processes and have different rankings. There are
six kinds of RFCs:
- Proposed standards
- Draft standards
- Internet standards (sometimes called "full standards")
- Experimental protocols
- Informational documents
- Historic standards
Only the first three (proposed, draft, and full) are standards within
the IETF. A good summary of this can be found in the aptly titled
RFC1796, "Not All RFCs are Standards."
There are also three sub-series of RFCs, known as FYIs, BCPs, and
STDs. The For Your Information RFCsub-series was created to
document overviews and topics which are introductory or appeal to a
broad audience. Frequently, FYIs are created by groups within the
IETF User Services Area. Best Current Practice documents describe
the application of various technologies in the Internet. The STD RFC
sub-series was created to identify RFCs that do in fact specify
Internet standards. Some STDs are actually sets of more than one
RFC, and the "standard" designation applies to the whole set of
documents.
6.2 Letting Go Gracefully
The biggest reason some people do not want their documents put on the
IETF standards track is that they must give up change control of the
protocol. That is, as soon as you propose that your protocol become
an IETF standard, you must fully relinquish control of the protocol.
If there is general agreement, parts of the protocol can be
completely changed, whole sections can be ripped out, new things can
be added, and the name can be changed.
Some authors find it very hard to give up control of their pet
protocol. If you are one of those people, don't even think about
trying to get your protocol to become an IETF standard. On the other
hand, if your goal is the best standard possible with the widest
implementation, then you might find the IETF process to your liking.
Incidentally, the change control on Internet standards doesn't end
when the protocol is put on the standards track. The protocol itself
can be changed later for a number of reasons, the most common of
which is that implementors discover a problem as they implement the
standard. These later changes are also under the control of the
IETF, not the editors of the standards document.
IETF standards exist so that people will use them to write Internet
programs that interoperate. They don't exist to document the
(possibly wonderful) ideas of their authors, nor do they exist so
that a company can say "we have an IETF standard." If a standards-
track RFConly has one implementation (whereas two are required for
it to advance on the standards track), it was probably a mistake to
put it on the standards track in the first place.
6.3 Internet Drafts
First things first. Every document that ends up in the RFC
repository starts life as an Internet Draft. Internet Drafts are
tentative documents -- they're meant for readers to comment on, so
authors can mull over those comments and decide which ones to
incorporate in the draft. In order to remind folks of their
tentativeness, Internet Drafts are automatically removed from the
online directories after six months. They are most definitely not
standards or even specifications. As BCP 9 says:
An Internet Draft is NOT a means of "publishing" a specification;
specifications are published through the RFCmechanism ...
Internet Drafts have no formal status, and are subject to change
or removal at any time. Under no circumstances should an Internet
Draft be referenced by any paper, report, or Request-for-Proposal,
nor should a vendor claim compliance with an Internet Draft.
You can always tell a person who doesn't understand the IETF (or is
intentionally trying to fool people) when they brag about having
published an Internet Draft; it takes no significant effort.
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
RFCEditor 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 RFCAuthors," describes the nroff formatting used by
the RFCEditor.
An Internet Draft can be either a Working Group draft or an
individual submission. Working Group drafts are usually reviewed by
the chair before being accepted as a WG item.
6.3.1 Recommended Reading for Writers
Before you create the first draft of your Internet Draft, you should
read four documents:
- 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.
- BCP 22, "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.
- 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.
- 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 "Considerations for Internet Drafts,"
http://www.ietf.org/ID-nits.html, a list of common "nits" 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.
6.3.2 Filenames and Other Matters
When you're ready to turn in your Internet Draft, send it to the
Internet Drafts editor at internet-drafts@ietf.org. There is a real
person at the other end of this mail address -- their 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, the draft editor supplies the 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, the author
sometimes follows 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 editor (and, if it is
an official WG draft, the WG chair) to come up with the filename.
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 the first version,
such as when a personal effort is pulled into a Working Group.
6.4 Standards-Track RFCs
The procedure for creating and advancing a standard is described in
BCP 9. 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 it 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 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 RFCEditor 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 while
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." This doesn't
happen often, and 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 before making a Draft Standard an
Internet Standard.
6.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.
RFC1123, "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 BCP 14, "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 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 RFC2119, 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 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.
6.4.2 Normative References in Standards
One aspect of writing IETF standards that trips up many novices (and
quite a few long-time IETF folk) 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 is one that is helpful to an implementor but is not needed.
As we noted above, a "MUST" specification would certainly be
normative, so any reference needed to implement the "MUST" would be
normative. A "SHOULD" or "MAY" specification is not necessarily
normative, but it could be normative based on what is being required.
There is definitely room for debate here!
An IETF standard may make a normative reference to any other
standards-track RFCthat 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.
6.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 1.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 an IANA registry
needs to read BCP 26, "Guidelines for Writing an IANA Considerations
Section in RFCs," which describes how RFCauthors 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.
6.4.4 Security Considerations
One thing that's required in every RFCis 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.
6.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. You can read about the official rules in BCP
9, but you should assume that the application of those rules is
flexible and depends on the type of patent, the patent holder, and
the availability of alternate technologies that are not encumbered by
patents.
Patent holders who freely allow their patents to be used by people
implementing IETF standards often get a great deal of good will from
the folks in the IETF. Such generosity is more common than you might
think. For example, RFC1822 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, send a note to the IETF Secretariat
(ietf-secretariat@ietf.org) about the patent or other intellectual
property rights. The note will be published on the IETF IPR web page
(http://www.ietf.org/ipr.html). 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 a RFCcould be incomplete and mislead the reader. BCP 9 provides
specific text that should be added to RFCs where the author knows of
IPR issues.
6.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, Historical, 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. That is, a specification might solve a problem,
but if it is not clear 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, 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.
7. How to Contribute to the IETF -- 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.
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.
7.1 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 them 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 importantly, 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.
8. IETF and the Outside World
8.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 who
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, 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 IESG has some liaisons with large
standards bodies, including the ITU (International Telecommunication
Union), the W3C, the Unicode Consortium, the ATM Forum, and ISO-
IEC/JTC1 (The Joint Technical Committee of the International
Organization for Standardization and International Electrotechnical
Commission). The list of IETF liaisons, www.ietf.org/ietf/1iesg-
liaisons.txt, shows that there are many different liaisons to ISO-
IEC/JTC1 subcommittees.
8.2 Press Coverage of the IETF
Given that the IETF is one of the best-known bodies that is helping
move the Internet forward, it's natural for the computer press (and
even the trade press) to want to cover its actions. In recent years,
a small number of magazines have assigned reporters and editors to
cover the IETF in depth over a long period of time. These reporters
have ample scars from articles that they got wrong, incorrect
statements about the status of Internet Drafts, quotes from people
who are unrelated to the IETF work, and so on.
Major press errors fall into two categories: saying that the IETF is
considering something when in fact there is just an Internet Draft in
a Working Group, and saying that the IETF approved something when all
that happened was that an Informational RFCwas published. In both
cases, the press is not fully to blame for the problem, since they
are usually alerted to the story by a company trying to get publicity
for a protocol that they developed or at least support. Of course, a
bit of research by the reporter would probably get them in contact
with someone who could straighten them out, such as a WG chair or an
Area Director. The official press contact for the IETF is the IETF
Secretariat.
The fact that those reporters who've gotten it wrong once come back
to IETF meetings shows that it is possible to get it right
eventually. However, IETF meetings are definitely not for reporters
who are naive about the IETF process (although if you are a reporter
the fact that you are reading this document is a very good sign!).
Further, if you think that you'll get a hot story from attending an
IETF meeting, you are likely to be disappointed.
Considering all this, it's not surprising that some IETFers would
prefer to have the press stay as far away from meetings as possible.
Having a bit of press publicity for protocols that are almost near
completion and will become significant in the industry in the next
year can be a good thing. However, it is the rare reporter who can
resist over-hyping a nascent protocol as the next savior for the
Internet. Such stories do much more harm than good, both for the
readers of the article and for the IETF.
The main reason why a reporter might want to attend an IETF meeting
is not to cover hot technologies (since that can be done in the
comfort of your office by reading the mailing lists), but to meet
people face to face. Unfortunately, the most interesting people are
the ones who are also the busiest during the IETF meeting, and some
folks have a tendency to run away when they see a press badge.
However, IETF meetings are excellent places to meet and speak with
document authors and Working Group chairs; this can be quite valuable
for reporters who are covering the progress of protocols.
Reporters who want to find out about "what the IETF is doing" on a
particular topic would be well-advised to talk to more than one
person who is active on that topic in the IETF, and should probably
try to talk to the WG chair in any case. It's impossible to
determine what will happen with a draft by looking at the draft or
talking to the draft's author. Fortunately, all WGs have archives
that a reporter can look through for recent indications about what
the progress of a draft is; unfortunately, few reporters have the
time or inclination to do this kind of research. Because the IETF
doesn't have a press liaison, a magazine or newspaper that runs a
story with errors won't hear directly from the IETF and therefore
often won't know what they did wrong, so they might easily do it
again later.
9. References
9.1 Tao
Pronounced "dow", Tao is the basic principle behind the teachings of
Lao-tse, a Chinese master. Its familiar symbol is the black and
white Yin-Yang circle. Taoism conceives the universe as a single
organism, and human beings as interdependent parts of a cosmic whole.
Tao is sometimes translated "the way," but according to Taoist
philosophy the true meaning of the word cannot be expressed in words.
9.2 Useful E-mail Addresses
agenda@ietf.org Requests for agenda slots at IETF
meetings
ietf-info@ietf.org General questions about the IETF
ietf-registrar@ietf.org Questions about registration, meeting
locations, and fees
ietf-request@ietf.org Requests to join/leave IETF lists
ietf-secretariat@ietf.org Questions for the Secretariat
ietf-web@ietf.org Web questions/comments
internet-drafts@ietf.org Internet Draft submissions and queries
minutes@ietf.org Where to send Working Group minutes
proceedings@ietf.org IETF Proceedings Coordinator
iana@iana.org Internet Assigned Numbers Authority
rfc-ed@rfc-editor.org RFCEditor
9.3 Useful Documents and Files
The IETF web site, http://www.ietf.org, is the best source for
information about meetings, Working Groups, Internet Drafts, RFCs,
IETF e-mail addresses, and much more. Click on "Additional
Information" to find a variety of helpful links. Internet Drafts and
other documents are also available in the "ietf" directory on
anonymous FTP sites worldwide. For a listing of these sites, see:
http://www.ietf.org/shadow.html
Check the IESG web pages, http://www.ietf.org/iesg.html, to find
up-to-date information about drafts processed, RFCs published, and
documents in Last Call, as well as the monthly IETF status reports.
9.4 Acronyms and Abbreviations Used in the Tao
AD Area Director
BCP Best Current Practice
BOF Birds Of a Feather
FAQ Frequently Asked Question(s)
FYI For Your Information (RFC)
IAB Internet Architecture Board
IANA Internet Assigned Numbers Authority
ICANN Internet Corporation for Assigned Names and Numbers,
http://www.icann.org/
I-D Internet Draft
IESG Internet Engineering Steering Group,
http://www.ietf.org/iesg.html
IETF Internet Engineering Task Force, http://www.ietf.org/
INET Internet Society Conference,
http://www.isoc.org/isoc/conferences/inet/
IRTF Internet Research Task Force, http://www.irtf.org/
ISO International Organization for Standardization,
http://www.iso.ch/
ISO-IEC/JTC1
Joint Technical Committee of the International
Organization for Standardization and International
Electrotechnical Commission, http://www.jtc1.org/
ISOC Internet Society, http://www.isoc.org
ITU International Telecommunication Union, http://www.itu.int
RFCRequest For Comments
STD Standard (RFC)
W3C World Wide Web Consortium, http://www.w3.org/
WG Working Group
9.5 Documents Cited in the Tao
BCP 9 "The Internet Standards Process"
BCP 10 "IAB and IESG Selection, Confirmation, and Recall Process:
Operation of the Nominating and Recall Committees"
BCP 11 "The Organizations Involved in the IETF Standards Process"
BCP 14 "Key words for use in RFCs to Indicate Requirement Levels"
BCP 22 "Guide for Internet Standards Writers"
BCP 25 "IETF Working Group Guidelines and Procedures"
BCP 26 "Guidelines for Writing an IANA Considerations Section
in RFCs"
RFC1123 "Requirements for Internet Hosts -- Application and
Support"
RFC1796 "Not All RFCs are Standards"
RFC2223 "Instructions to RFCAuthors"
"Considerations for Internet Drafts,"
http://www.ietf.org/ID-nits.html
"Guidelines to Authors of Internet-Drafts,"
ftp://ftp.ietf.org/ietf/1id-guidelines.txt
Security Considerations
Section 6.4.5 explains why each RFCis required to have a Security
Considerations section, and gives some idea of what it should and
should not contain. Other than that information, this document does
not touch on Internet security.
Editor's Address
Susan Harris
Merit Network, Inc.
4251 Plymouth Road, Suite 2000
Ann Arbor, MI 48105
EMail: srh@merit.edu
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.