Internet Engineering Task Force S. Harris, Editor
INTERNET-DRAFT Merit Network
February 14, 2001
The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force
<draft-ietf-uswg-tao-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
For the benefit of users who are new to the Internet Engineering Task
Force, this document describes the inner workings of IETF meetings
and Working Groups, discusses organizations related to the IETF, and
introduces the standards process.
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3
1. What Is the IETF? . . . . . . . . . . . . . . . . . . . . . 4
1.1 Humble Beginnings . . . . . . . . . . . . . . . . . . 4
1.2 The Hierarchy . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 IESG . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 IAB . . . . . . . . . . . . . . . . . . . . . . 7
Harris [Page 1]
INTERNET-DRAFT The Tao of IETF February 2001
1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 RFC Editor . . . . . . . . . . . . . . . . . . . 8
1.2.6 IETF Secretariat . . . . . . . . . . . . . . . . 9
1.3 IETF Mailing Lists . . . . . . . . . . . . . . . . . 9
2. IETF Meetings . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Registration . . . . . . . . . . . . . . . . . . . . . 11
2.2 Newcomers' Orientation . . . . . . . . . . . . . . . . 11
2.3 Dress Code . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . . 12
2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . . 13
2.6 Meals and Other Delights . . . . . . . . . . . . . . . . 13
2.7 Social Event . . . . . . . . . . . . . . . . . . . . . 13
2.8 Agenda . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Where Do I Fit In? . . . . . . . . . . . . . . . . . . . 14
2.9.1 IS Managers . . . . . . . . . . . . . . . . . 14
2.9.2 Network Operators and ISPs . . . . . . . . . . . 15
2.9.3 Networking Hardware and Software Vendors . . . . 15
2.9.4 Academics . . . . . . . . . . . . . . . . . . . 15
2.9.5 Computer Trade Press . . . . . . . . . . . . . . 16
2.10 Proceedings . . . . . . . . . . . . . . . . . . . . . 16
2.11 Other General Things . . . . . . . . . . . . . . . . . 16
3. Working Groups . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Working Group Chairs . . . . . . . . . . . . . . . . . .17
3.2 Getting Things Done in a Working Group . . . . . . . . . 18
3.3 Preparing for Working Group Meetings . . . . . . . . 19
3.4 Working Group Mailing Lists . . . . . . . . . . . . . 19
3.5 Interim Working Group Meetings . . . . . . . . . . . . 20
4. BOFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
**5. New to the IETF? STOP HERE! (Temporarily) . . . . . . . . . 21
6. RFCs and Internet Drafts . . . . . . . . . . . . . . . . . 21
6.1 Getting a Standard Published . . . . . . . . . . . . . 22
6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . . 23
6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . 23
6.3.1 Recommended Reading for Writers . . . . . . . . 24
6.3.2 Filenames and Other Matters . . . . . . . . . . 25
6.4 Standards-Track RFCs . . . . . . . . . . . . . . . . . 25
6.4.1 Telling It Like It Is -- Using MUST and
SHOULD and MAY . . . . . . . . . . . . . . . . . . 27
6.4.2 Normative References in Standards . . . . . . . . 28
6.4.3 IANA Considerations . . . . . . . . . . . . . . . 29
6.4.4 Security Considerations . . . . . . . . . . . . . 29
6.4.5 Patents in IETF Standards . . . . . . . . . . . . 29
6.5 Informational and Experimental RFCs . . . . . . . . . . 30
7. How to Contribute to the IETF -- What You Can Do . . . . . . 31
7.1 What Your Company Can Do . . . . . . . . . . . . . . . 31
8. IETF and the Outside World . . . . . . . . . . . . . . . . . 32
8.1 IETF and Other Standards Groups . . . . . . . . . . . . 32
8.2 Press Coverage of the IETF . . . . . . . . . . . . . . 32
Harris [Page 2]
INTERNET-DRAFT The Tao of IETF February 2001
9. References . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . . 34
9.3 Useful Documents and Files . . . . . . . . . . . . . . 34
9.4 Acronyms Used in the Tao . . . . . . . . . . . . . . . 34
9.5 Documents Cited in the Tao . . . . . . . . . .. . . . . 35
Introduction
Over the last several years, attendance at Internet Engineering Task
Force (IETF) face-to-face meetings has grown phenomenally. Many of
the attendees are new to the IETF at each meeting, and many of those
go on to become regular attendees. When the meetings were smaller, it
was relatively easy for a newcomer to get into the swing of things.
Today, however, a newcomer meets many more new people, some
previously known only as the authors of documents or thought-
provoking e-mail messages.
This document describes many aspects of the IETF, with the goal of
explaining to newcomers how the IETF works. This will give them a
warm, fuzzy feeling and enable them to make the meeting and the
Working Group discussions more productive for everyone.
Of course, it's true that many IETF participants don't go to the
face-to-face meetings at all. Instead, they're active on the mailing
list of various IETF Working Groups. Since the inner workings of
Working Groups can be hard for newcomers to understand, this FYI
provides the mundane bits of information that newcomers will need in
order to become active participants.
Many types of IETF documentation are mentioned in the Tao, from BCPs
to RFCs. (BCPs make recommendations for Best Current Practices in
the Internet, and RFCs are the IETF's main technical documentation
series, politely known as "Requests for Comments.") See Section 5
for more information.
The acronyms used in this document are usually expanded in place, and
are explained fully in Section 9.
Acknowledgements
The original version of this document, published in 1994, was written
by Gary Malkin. His knowledge of the IETF, insights, and unmatched
writing style set the standard for this later revision, and his
contributions to the current draft are also much appreciated. Paul
Hoffman wrote significant portions of this revision and provided
encouragement, expertise, and much-needed guidance. Other
contributors include Scott Bradner, Michael Patton, Donald E.
Harris [Page 3]
INTERNET-DRAFT The Tao of IETF February 2001
Eastlake III, the IETF Secretariat, and members of the User Services
Working Group.
1. What Is the IETF?
The Internet Engineering Task Force is a loosely self-organized group
of people who contribute to the engineering and evolution of Internet
technologies. It is the principal body engaged in the development of
new Internet standard specifications. The IETF is unusual in that it
exists as a collection of happenings, but is not a corporation and
has no board of directors, no members, and no dues.
Its mission includes:
- Identifying, and proposing solutions to, pressing operational and
technical problems in the Internet;
- Specifying the development or usage of protocols and the near-term
architecture to solve such technical problems for the Internet;
- Making recommendations to the Internet Engineering Steering Group
(IESG) regarding the standardization of protocols and protocol
usage in the Internet;
- Facilitating technology transfer from the Internet Research Task
Force (IRTF) to the wider Internet community; and
- Providing a forum for the exchange of information within the
Internet community between vendors, users, researchers, agency
contractors, and network managers.
The IETF meeting is not a conference, although there are technical
presentations. The IETF is not a traditional standards organization,
although many specifications are produced that become standards. The
IETF is made up of volunteers, many of whom meet three times a year
to fulfill the IETF mission.
There is no membership in the IETF. Anyone may register for and
attend any meeting. The closest thing there is to being an IETF
member is being on the IETF or Working Group mailing lists (see
section 1.3). This is where the best information about current IETF
activities and focus can be found.
Of course, no organization can be as successful as the IETF is
without having some sort of structure. In the IETF's case, that
structure is provided by other organizations, as described in BCP 11,
"The Organizations Involved in the IETF Standards Process." If you
participate in the IETF and only read one BCP, this is the one you
Harris [Page 4]
INTERNET-DRAFT The Tao of IETF February 2001
should read.
1.1 Humble Beginnings
The first IETF meeting was held in January, 1986, at Linkabit in San
Diego, with 15 attendees. The 4th IETF, held at SRI in Menlo Park in
October, 1986, was the first that non-government vendors attended.
The concept of Working Groups was introduced at the 5th IETF meeting
at the NASA Ames Research Center in California in February, 1987. The
7th IETF, held at MITRE in McLean, Virginia in July, 1987, was the
first meeting with over 100 attendees.
The 14th IETF meeting was held at Stanford University in July 1989.
It marked a major change in the structure of the IETF universe. The
IAB (then Internet Activities Board, now Internet Architecture
Board), which until that time oversaw many "task forces," changed its
structure to leave only two: the IETF and the IRTF. The IRTF is
tasked to consider long-term research problems in the Internet. The
IETF also changed at that time.
After the Internet Society (ISOC) was formed in January, 1992, the
IAB proposed to ISOC that the IAB's activities should take place
under the auspices of the Internet Society. During INET92 in Kobe,
Japan, the ISOC Trustees approved a new charter for the IAB to
reflect the proposed relationship.
The IETF met in Amsterdam, The Netherlands, in July 1993. This was
the first IETF meeting held in Europe, and the US/non-US attendee
split was nearly 50/50. One in five IETF meetings are now held in
Europe or Asia, and the number of non-US attendees continues to be
high -- about 50%, even at meetings held in the US.
1.2 The Hierarchy
1.2.1 ISOC (Internet Society)
The Internet Society is an international, non-profit, membership
organization that fosters the expansion of the Internet. One of the
ways that ISOC does this is through financial and legal support of
the other "I" groups described here, particularly the IETF. ISOC's
oversight of the IETF is remarkably hands-off, so many IETF
participants don't even know about it. ISOC provides insurance
coverage for many of the people in the IETF process, and acts as a
public relations channel for the times that one of the "I" groups
wants to say something to the press. The ISOC is one of the major
unsung (and underfunded) heroes of the Internet.
1.2.2 IESG (Internet Engineering Steering Group)
Harris [Page 5]
INTERNET-DRAFT The Tao of IETF February 2001
The IESG is responsible for technical management of IETF activities
and the Internet standards process. It administers the process
according to the rules and procedures that have been ratified by the
ISOC Trustees. However, the IESG doesn't do much direct leadership,
such as the kind you will find in many other standards organizations.
The IESG ratifies or corrects the output from the IETF's Working
Groups, gets WGs started and finished, and makes sure that non-WG
drafts that are about to become RFCs are correct.
The IESG consists of the Area Directors ("ADs"), who are selected by
the Nominations Committee (which is usually called "Nomcom") and are
appointed for two years. The process for choosing the members of the
IESG is detailed in BCP 10, "IAB and IESG Selection, Confirmation,
and Recall Process: Operation of the Nominating and Recall
Committees."
The current areas and abbreviations are:
- Applications (APP) Protocols seen by user programs, such as e-mail
and the Web
- General (GEN) Catch-all for WGs that don't fit in other areas
(which is very few)
- Internet (INT) Different ways of moving IP packets and DNS
information
- Operations and
Management (OPS) Administration and monitoring
- Routing (RTG) Getting packets to their destinations
- Security (SEC) Authentication and privacy
- Transport (TSV) Special services for special packets
- User Services (USV) Support for end users and user support
organizations
Because the IESG has a great deal of influence on whether Internet
Drafts become RFCs, many people look at the ADs as somewhat godlike
creatures. IETF participants sometimes reverently ask an Area
Director for their opinion on a particular subject. However, most ADs
are nearly indistinguishable from mere mortals and rarely speak from
mountaintops. In fact, when asked for specific technical comments,
the ADs may often defer to members at large whom they feel have more
knowledge than they do in that area.
The ADs for a particular area are expected to know more about the
combined work of the WGs in that area than anyone else. On the other
hand, the entire IESG votes on each Internet Draft that is becoming
an RFC, and it only takes two IESG members to block a draft from
moving forward. This ensures that an AD's "pet project" doesn't make
it onto the standards track if it will have a negative effect on the
rest of the IETF protocols.
Harris [Page 6]
INTERNET-DRAFT The Tao of IETF February 2001
This is not to say that the IESG never wields power. When the IESG
sees a Working Group veering from its charter, or when a WG asks the
IESG to make the WG's badly designed protocol a standard, the IESG
will act. In fact, because of its high workload, the IESG usually
moves in a reactive fashion. It approves most WG requests for
Internet Drafts to become RFCs, and usually only steps in when
something has gone very wrong. Another way to think about this is
that the ADs are selected to think, not to just run the process. The
quality of the IETF standards comes both from the review they get in
the Working Groups and the review that the WG review gets from the
ADs.
The IETF is run by rough consensus, and it is the IESG that decides
if a WG has come up with a result that has a real consensus. Because
of this, one of the main reasons that the IESG might block something
that was produced in a WG is that the result did not really gain
consensus in the IETF as a whole, that is, among all of the WGs in
all areas. For instance, the result of one WG might clash with a
technology developed in a different WG. An important job of the IESG
is to watch over the output of all the WGs to help prevent IETF
protocols that are at odds with each other. This is why ADs are
supposed to review the drafts coming out of areas other than their
own.
1.2.3 IAB (Internet Architecture Board)
The IAB is responsible for keeping an eye on the "big picture" of the
Internet, and focuses on long-range planning and coordination among
the various areas of IETF activity. The IAB stays informed about
important long-term issues in the Internet, and brings these topics
to the attention of people they think should know about them.
IAB members pay special attention to emerging activities in the IETF.
When a new IETF working group is proposed, the IAB reviews its
charter for architectural consistency and integrity. Even before the
group is chartered, the IAB members are more than willing to discuss
new ideas with the people proposing them.
The IAB also sponsors and organizes the Internet Research Task Force,
and convenes invitational workshops that provide in-depth reviews of
specific Internet architectural issues. Typically, the workshop
reports make recommendations to the IETF community and to the IESG.
The IAB also:
- Approves Nomcom's IESG nominations
- Acts as the appeals board for appeals against IESG actions
- Appoints and oversees the RFC Editor
Harris [Page 7]
INTERNET-DRAFT The Tao of IETF February 2001
- Approves the appointment of the IANA
- Acts as an advisory body to the ISOC
- Oversees IETF liaisons with other standards bodies
Like the IESG, the IAB members are selected for multi-year positions
by the Nomcom, and are approved by the Board of Trustees of the ISOC.
1.2.4 IANA (Internet Assigned Numbers Authority)
The core registrar for the IETF's activities is the IANA. Many
Internet protocols require that someone keep track of protocol items
that were added after the protocol came out. Typical examples of the
kinds of registries needed are for TCP port numbers and MIME types.
The IANA organization is approved by the IAB and these days is paid
for by ICANN, the Internet Corporation for Assigned Names and
Numbers.
Five years ago, no one would have expected to ever see the IANA
mentioned on the front page of a newspaper. IANA's role had always
been very low key. The fact that IANA was also the keeper of the
root of the domain name system forced it to become a much more public
entity, one which was badly maligned by a variety of people who never
looked at what its role was. Nowadays the domain name and IP address
assignment functions are no longer part of the IETF's IANA, and are
overseen by ICANN.
Even though being a registrar may not sound interesting, many IETF
participants will testify to how important IANA has been for the
Internet. Having a stable, long-term repository run by careful and
conservative operators makes it much easier for people to experiment
without worrying about messing things up. IANA's founder, Jon Postel,
was heavily relied upon to keep things in order while the Internet
kept growing in leaps and bounds, and he did a fine job of it until
his death in 1998.
1.2.5 RFC Editor
The RFC Editor edits, formats, and publishes Internet Drafts as RFCs,
working in conjunction with the IESG. An important secondary role is
to provide one definitive repository for all RFCs (see www.rfc-
editor.org). Once an RFC is published, it is never revised. If the
standard it describes changes, the standard will be re-published in
another RFC that "obsoletes" the first.
One of the most popular misconceptions in the IETF community is that
the role of the RFC Editor is performed by IANA. In fact, the RFC
Editor is a separate job, although both the RFC Editor and IANA
involved the same people for many years. The IAB approves the
Harris [Page 8]
INTERNET-DRAFT The Tao of IETF February 2001
organization that will act as RFC Editor and the RFC Editor's general
policy. The RFC Editor is funded by ISOC and can be contacted by e-
mail at rfc-ed@rfc-editor.org.
1.2.6 IETF Secretariat
There are, in fact, a few people who are paid to maintain the IETF.
The IETF Secretariat provides day-to-day logistical support, which
mainly means coordinating face-to-face meetings and running the
IETF-specific mailing lists (not the WG mailing lists). The
Secretariat is also responsible for keeping the official Internet
Drafts directory up to date and orderly, maintaining the IETF Web
site, and for helping the IESG do its work. The IETF Secretariat is
financially supported by the fees of the face-to-face meetings.
1.3 IETF Mailing Lists
Anyone who plans to attend an IETF meeting should join the IETF
announcement mailing list, "ietf-announce@ietf.org." This is where
all of the meeting information, Internet Draft and RFC announcements,
and IESG Protocol Actions and Last Calls are posted. People who
would like to "get technical" may also join the IETF discussion list,
"ietf@ietf.org." This is where discussions of cosmic significance are
held (Working Groups have their own mailing lists for discussions
related to their work).
Subscriptions to these and other IETF mailing lists are handled by a
program called Majordomo. Majordomo tends to be somewhat finicky
about the format of subscription messages, and interacts poorly with
email programs that make all email messages into HTML files.
Majordomo will treat you well, however, if you format your messages
just the way it likes. To join the IETF announcement list, for
example, send email to:
ietf-announce-request@ietf.org
Enter the word 'subscribe' (without the quotes) in the Subject line
of the message and in the message body. To join the IETF discussion
list, send email to:
ietf-request@ietf.org
and enter the word 'subscribe' as explained above. If you decide to
withdraw from either list, use the word 'unsubscribe.' Your messages
to Majordomo should have nothing other than the commands 'subscribe'
or 'unsubscribe' in them.
Both lists are archived on the IETF web site:
Harris [Page 9]
INTERNET-DRAFT The Tao of IETF February 2001
http://www.ietf.org/maillist.html
Do not, ever, under any circumstances, for any reason, send a request
to join a list to the list itself! The thousands of people on the
list don't need, or want, to know when a new person joins. Similarly,
when changing e-mail addresses or leaving a list, send your request
only to the "-request" address, not to the main list. This means
you!!
The IETF discussion list is unmoderated. This means that anyone can
express their opinions about issues affecting the Internet. However,
it is not a place for companies or individuals to solicit or
advertise, as noted in "IETF Discussion List Charter," RFC 3005. It
is a good idea to read the whole RFC (it's short!) before posting to
the IETF discussion list.
Only the Secretariat can send messages to the announcement list.
Even though the IETF mailing lists "represent" the IETF membership at
large, it is important to note that attending an IETF meeting does
not automatically include addition to either mailing list.
2. IETF Meetings
The computer industry is rife with conferences, seminars,
expositions, and all manner of other kinds of meetings. IETF face-
to-face meetings are nothing like these. The meetings, held three
times a year, are week-long dweebfests whose primary goal is to
reinvigorate the WGs to get their tasks done, and whose secondary
goal is to promote a fair amount of mixing between the WGs and the
areas. The cost of the meetings is paid by the people attending the
meetings and by the corporate host for each meeting, although ISOC
kicks in additional funds for things like the multicast simulcast of
some Working Group sessions.
For many people, IETF meetings are a breath of fresh air when
compared to the standard computer industry conferences. There is no
exposition hall, few tutorials, and no big-name industry pundits.
Instead, there is lots of work, as well as a fair amount of time for
socializing. IETF meetings are of little interest to sales and
marketing folks, but of high interest to engineers and developers.
Most IETF meetings are held in North America, because that's where
most of the participants are from; however, meetings are held on
other continents about once every year or two. The past few meetings
have had about 2,500 attendees. There have been over 49 IETF meetings
so far, and a list of upcoming meetings is available on the IETF web
pages, http://www.ietf.org/meetings/0mtg-sites.txt.
Harris [Page 10]
INTERNET-DRAFT The Tao of IETF February 2001
Newcomers to IETF face-to-face meetings are often in a bit of shock.
They expect them to be like other standards bodies, or like computer
conferences. Fortunately, the shock wears off after a day or two, and
many new attendees get quite animated about how much fun they are
having. One particularly jarring feature of recent IETF meetings is
the use of wireless Internet connections throughout the meeting
space. It is common to see half the people in a WG meeting reading
e-mail or perusing the web during presentations they find
uninteresting.
2.1 Registration
To attend an IETF meeting you have to register and you have to pay
the registration fee. The meeting site and advance registration are
announced about two months ahead of the meeting -- earlier if it is
outside the U.S. An announcement goes out via e-mail to the IETF-
announce mailing list, and information is posted on the IETF web
site, http://www.ietf.org, that same day.
You may pre-register and pay, pre-register and pay later, pre-
register and pay on-site, or register and pay on-site. To get a
lower registration fee, you must register by the early registration
deadline (about one month before the meeting). You can still pay
later or on-site, but you'll end up paying a higher fee. The
registration fee covers all of the week's meetings, the Sunday
evening reception (cash bar), daily continental breakfasts, and daily
coffee breaks.
The easiest way to register in advance is via the web. Credit card
payments on the web are encrypted and secure, or, if you prefer. you
can use PGP to send your payment information to the Registrar
(registrar@ietf.org).
Registration is open throughout the week of the meeting. However,
the Secretariat highly recommends that attendees arrive for early
registration, beginning at noon on Sunday and continuing throughout
the 5:00 Sunday evening reception. The reception is a popular event
where you can get a bite to eat and socialize with other early
arrivals.
Registered attendees (and there aren't any other kind) receive a
registration packet. It contains a general orientation sheet, a list
of Working Group acronyms, the most recent agenda, and a name tag.
Attendees who pre-paid will also find their receipt in their packet.
It's worth noting that neither attendee names and addresses or IETF
mailing lists are ever offered for sale.
Harris [Page 11]
INTERNET-DRAFT The Tao of IETF February 2001
2.2 Newcomers' Orientation
Newcomers are encouraged to attend the Newcomers Orientation, which
is especially designed for first-time attendees. The orientation is
organized and conducted by the IETF Secretariat, and is intended to
provide useful introductory information. The orientation is typically
about 30 minutes long and covers a number of topics: what's in the
attendee packets, what all the dots on name tags mean, how to read
the at-a-glance, and the structure of the IETF. Immediately following
the newcomer orientation is the IETF Standards Process Orientation.
This provides an introduction to the Internet standards process,
including what stages a document must pass through and what must be
done to advance to the next stage. This also lasts about 30 minutes.
There is ample time at the end for questions. The Secretariat also
provides handouts that include an overview of the IETF, a list of
important files available online, and hard copies of the slides of
the "IETF Structure and Internet Standards Process" presentation.
These very useful slides are also available online at www.ietf.org
under "Additional Information."
The orientation is held on Sunday afternoon before the 5:00 p.m.
reception (check the agenda for exact time and location). Be advised
that attending the orientation does NOT mean you can go to the
reception early!
2.3 Dress Code
Since attendees must wear their name tags, they must also wear shirts
or blouses. Pants or skirts are also highly recommended. Seriously
though, many newcomers are often embarrassed when they show up Monday
morning in suits, to discover that everybody else is wearing t-
shirts, jeans (shorts, if weather permits) and sandals. There are
those in the IETF who refuse to wear anything other than suits.
Fortunately, they are well known (for other reasons) so they are
forgiven this particular idiosyncrasy. The general rule is "dress for
the weather" (unless you plan to work so hard that you won't go
outside, in which case, "dress for comfort" is the rule!).
2.4 Seeing Spots Before Your Eyes
Some of the people at the IETF will have a little colored dot on
their name tag. A few people have more than one. These dots identify
people who are silly enough to volunteer to do a lot of extra work.
The colors have the following meanings:
blue - Working Group/BOF chair
green - Local host
Harris [Page 12]
INTERNET-DRAFT The Tao of IETF February 2001
red - IAB member
yellow - IESG member
orange - Nominating Committee member
(Members of the press wear orange-tinted badges.)
Local hosts are the people who can answer questions about the
terminal room, restaurants, and points of interest in the area.
It is important that newcomers to the IETF not be afraid to strike up
conversations with people who wear these dots. If the IAB and IESG
members and Working Group and BOF chairs didn't want to talk to
anybody, they wouldn't be wearing the dots in the first place.
2.5 Terminal Room
One of the most important (depending on your point of view) things
the local host does is provide Internet access for the meeting
attendees. In general, wired and wireless connectivity is excellent.
This is entirely due to the Olympian efforts of the local hosts, and
their ability to beg, borrow and steal. The people and companies who
donate their equipment, services and time are to be heartily
congratulated and thanked.
While preparation far in advance of the meeting is encouraged, there
may be some unavoidable "last minute" things that can be accomplished
in the terminal room. It may also be useful to people who need to
make trip reports or status reports while things are still fresh in
their minds. The terminal room provides workstations, one or two
printers, and ports for laptops.
2.6 Meals and Other Delights
Marshall Rose once remarked that the IETF was a place to go for "many
fine lunches and dinners." While it is true that some people eat very
well at the IETF, they find the food on their own; lunches and
dinners are not included in the registration fee. The Secretariat
does provide appetizers at the Sunday evening reception (not meant to
be a replacement for dinner), continental breakfast every morning,
and (best of all) cookies, brownies and other yummies during
afternoon breaks.
If you prefer to get out of the hotel for meals, the local host
usually provides a list of places to eat within easy reach of the
meeting site.
2.7 Social Event
Harris [Page 13]
INTERNET-DRAFT The Tao of IETF February 2001
Another of the most important things organized and managed by the
local hosts is the IETF social event. Sometimes, the social event is
a computer or high-tech related event. At the Boston IETF, for
example, the social was dinner at the Computer Museum. Other times,
the social might be a dinner cruise or a trip to an art gallery.
Newcomers to the IETF are encouraged to attend the social event.
Everyone is encouraged to wear their name tags and leave their
laptops behind. The social event is designed to give people a chance
to meet on a social, rather than technical, level.
2.8 Agenda
The agenda for the IETF meetings is a very fluid thing. It is sent,
in various forms, to the IETF announcement list three times prior to
the meeting, and is also available on the web. (The agenda for the
49th IETF, for example, is at
http://www.ietf.org/meetings/wg_agenda_49.html.) The final agenda is
included in the registration packets. Of course, "final" in the IETF
doesn't mean the same thing as it does elsewhere in the world. The
final agenda is simply the version that went to the printer. The
Secretariat will post agenda changes on the bulletin board near the
IETF registration desk (not the hotel registration desk).
Assignments for breakout rooms (where the Working Groups and BOFs
meet) and a map showing the room locations make up the at-a-glance
sheet (included in the registration packets). Room assignments are as
flexible as the agenda. Some Working Groups meet multiple times
during a meeting and every attempt is made to have a Working Group
meet in the same room for each session. Room assignment changes are
not necessarily permanent for the week. Always check the at-a-glance
first, then the bulletin board. When in doubt, check with a member of
the Secretariat at the registration desk.
2.9 Where Do I Fit In?
The IETF is different things to different people. There are many
people who have been very active in the IETF who have never attended
an IETF meeting. You should not feel obligated to come to an IETF
meeting just to get a feel for the IETF. The following guidelines
(based on stereotypes of people in various industries) might help you
decide whether you actually want to come and, if so, what might be
the best use of your time at your first meeting.
2.9.1 IS Managers
As discussed throughout this document, an IETF meeting is nothing
like any trade show you have attended. IETF meetings are singularly
Harris [Page 14]
INTERNET-DRAFT The Tao of IETF February 2001
bad places to go if your intention is to find out what will be hot in
the Internet industry next year. You can safely assume that going to
Working Group meetings will confuse you more than it will help you
understand what is happening, or will be happening, in the industry.
This is not to say that no one from industry should go to IETF
meetings. As an IS manager, you might want to consider sending
specific people who are responsible for technologies that are under
development in the IETF. As these people read the current Internet
Drafts and the traffic on the relevant Working Group lists, they will
get a sense of whether or not their presence would be worthwhile for
your company or for the Working Groups.
2.9.2 Network Operators and ISPs
Running a network is hard enough without having to grapple with new
protocols or new versions of the protocols with which you are already
dealing. If you work for the type of network that is always using the
very latest hardware and software, and you are following the relevant
Working Groups in your copious free time, you might find attending
the IETF meeting valuable. The closer you are to the bleeding edge of
networking, particularly in the areas of routing and switching, the
more likely it is that you will be able to learn and contribute at an
IETF meeting.
2.9.3 Networking Hardware and Software Vendors
The image of the IETF being mostly ivory tower academics may have
been true in the past, but the jobs of typical attendees are now in
industry. In most areas of the IETF, employees of vendors are the
ones writing the protocols and leading the Working Groups. Thus, it
is completely appropriate for vendors to attend. If you create
Internet hardware or software, and no one from your company has ever
attended an IETF meeting, it behooves you to come to a meeting if for
no other reason than to tell the others how relevant the meeting was
or was not to your business.
This is not to say that companies should close during IETF meeting
weeks and everyone should go to the meeting. Marketing folks, even
technical marketing folks, are usually safe in staying away from the
IETF as long as some of the technical people from the company are at
the meeting. Similarly, it isn't required, or likely useful, for
everyone from a technical department to go, particularly if they are
not all reading the Internet Drafts and following the Working Group
mailing lists. Many companies have just a few designated meeting
attendees who are chosen for their ability to do complete and useful
trip reports.
Harris [Page 15]
INTERNET-DRAFT The Tao of IETF February 2001
2.9.4 Academics
IETF meetings are often excellent places for computer science folk to
find out what is happening in the way of soon-to-be-deployed
protocols. Professors and grad students (and sometimes overachieving
undergrads) who are doing research in networking or communications
can get a wealth of information by following Working Groups in their
specific fields of interest. Wandering into different Working Group
meetings can have the same effect as going to symposia and seminars
in your department.
2.9.5 Computer Trade Press
If you're a member of the press and are considering attending IETF,
we've dedicated a special section of the Tao just to you -- please
see section 8.2.
2.10 Proceedings
IETF proceedings are compiled in the two months following each
meeting, and are available on the web and on CD. Printed proceedings
are available for past meetings. Be sure to glance through a copy --
the proceedings are filled with information about IETF that you're
not likely to find anywhere else. For example, you'll find snapshots
of most WG charters at the time of the meeting, giving you a better
understanding of the evolution of any given effort.
The proceedings usually start with an informative (and highly
entertaining) message from Steve Coya, the Executive Director of the
IETF. Each volume of contains the final (hindsight) agenda, an IETF
overview, area and Working Group reports, and slides from the
protocol and technical presentations. The Working Group reports and
presentations are sometimes incomplete, if the materials haven't been
turned in to the Secretariat in time for publication.
An attendee list is also included, and contains names, affiliations,
work and fax phone numbers, and e-mail addresses as provided on the
registration form. For information about obtaining copies of the
proceedings, see the Web listing at
http://www.ietf.org/proceedings/directory.html.
2.11 Other General Things
The IETF Secretariat, and IETFers in general, are very approachable.
Never be afraid to approach someone and introduce yourself. Also,
don't be afraid to ask questions, especially when it comes to jargon
and acronyms!
Harris [Page 16]
INTERNET-DRAFT The Tao of IETF February 2001
Hallway conversations are very important. A lot of very good work
gets done by people who talk together between meetings and over
lunches and dinners. Every minute of the IETF can be considered work
time (much to some people's dismay).
A "bar BOF" is an unofficial get-together, usually in the late
evening, during which a lot of work gets done over drinks. Bar BOFs
spring up in many different places around an IETF meeting, such as
restaurants, coffee shops, and (if we are so lucky) pools.
It's unwise to get between a hungry IETFer (and there isn't any other
kind) and coffee break brownies and cookies, no matter how
interesting a hallway conversation is.
IETFers are fiercely independent. It's safe to question opinions and
offer alternatives, but don't expect an IETFer to follow orders.
The IETF, and the plenary session in particular, are not places for
vendors to try to sell their wares. People can certainly answer
questions about their company and its products, but bear in mind that
the IETF is not a trade show. This does not preclude people from
recouping costs for IETF related t-shirts, buttons and pocket
protectors.
There is always a "materials distribution table" near the
registration desk. This desk is used to make appropriate information
available to the attendees (e.g., copies of something discussed in a
Working Group session, description of online IETF-related
information, etc.). Please check with the Secretariat before placing
materials on the desk; the Secretariat has the right to remove
material that they feel is not appropriate.
3.0 Working Groups (WGs)
The vast majority of the IETF's work is done in many "Working
Groups"; at the time of this writing, there are about 115 different
WGs. (The term "Working Group" is often seen capitalized, but
probably not for a very good reason.) BCP 25, "IETF Working Group
Guidelines and Procedures," is an excellent resource for anyone
participating in WG discussions.
A WG is really just a mailing list with a bit of adult supervision.
You "join" the WG by subscribing to the mailing list; all mailing
lists are open to anyone. Some IETF WG mailing lists only let
subscribers to the mailing list post to the mailing list, while
others let anyone post. Each WG has one or two chairs.
More importantly, each WG has a charter that the WG is supposed to
Harris [Page 17]
INTERNET-DRAFT The Tao of IETF February 2001
follow. The charter states the scope of discussion for the WG, as
well as its goals. The WG's mailing list and face-to-face meetings
are supposed to focus on just what is in the charter, and not to
wander off on other "interesting" topics. Of course, looking a bit
outside the scope of the WG is occasionally useful, but the large
majority of the discussion should be on the topics listed in the
charter. In fact, some WG charters actually specify what the WG will
not do, particularly if there were some attractive but nebulous
topics brought up during the drafting of the charter. The list of all
WG charters makes interesting reading for folks who want to know what
the different WGs are supposed to be doing.
3.1 Working Group Chairs
The role of the WG chairs is described in both BCP 11 and BCP 25.
Basically, their job is to keep the discussion moving forward towards
the milestones in the WG charter -- usually publication of one or
more RFCs. They are not meant to be taskmasters, but are responsible
for assuring positive forward motion and preventing random wandering.
As you can imagine, some WG chairs are much better at their jobs than
others. When a WG has fulfilled its charter, it is supposed to cease
operations. (Most WG mailing lists continue on after a WG is closed,
still discussing the same topics as the WG did.) In the IETF, it is a
mark of success that the WG closes up because it fulfilled its
charter. This is one of the aspects of the IETF that newcomers who
have experience with other standards bodies have a hard time
understanding. However, some WG chairs never manage to get their WG
to finish, or keep adding new tasks to the charter so that the WG
drags on for many years. The output of these aging WGs is often not
nearly as useful as the earlier products, and the messy results are
sometimes called "degenerative Working Group syndrome."
One important role of the chair is to decide which Internet Drafts
get published as "official" Working Group drafts, and which don't. In
practice, there is actually not much procedural difference between WG
drafts and independent drafts; for example, many WG mailing lists
also discuss independent drafts (at the discretion of the WG chair).
Procedures for Internet Drafts are covered in much more detail later
in this document.
WG chairs are strongly advised to go to the new chairs' training
lunch the first day of the IETF meeting. If you're interested in
what they hear there, take a look at the slides at
http://www.ietf.org/wgchair/index.htm.
3.2 Getting Things Done in a Working Group
Harris [Page 18]
INTERNET-DRAFT The Tao of IETF February 2001
One fact that confuses many novices is that the face-to-face WG
meetings are much less important in the IETF than they are in most
other organizations. Any decision made at a face-to-face meeting must
also gain consensus on the WG mailing list. There are numerous
examples of important decisions made in WG meetings that are later
overturned on the mailing list, often because someone who couldn't
attend the meeting pointed out a serious flaw in the logic used to
come to the decision.
Another aspect of Working Groups that confounds many people is the
fact that there is no formal voting. The general rule on disputed
topics is that the Working Group has to come to "rough consensus,"
meaning that a very large majority of those who care must agree. The
exact method of determining rough consensus varies from Working Group
to Working Group. The lack of voting has caused some very long delays
for some proposals, but most IETF participants who have witnessed
rough consensus after acrimonious debates feel that the delays often
result in better protocols. (And, if you think about it, how could
you have "voting" in a group that anyone can join, and when it's
impossible to count the participants?)
3.3 Preparing for Working Group Meetings
The most important thing that everyone (newcomers and seasoned
experts) should do before coming to a face-to-face meeting is to read
the Internet Drafts and RFCs beforehand. WG meetings are explicitly
not for education: they are for developing the group's documents.
Even if you do not plan to say anything in the meeting, you should
read the group's documents before attending so you can understand
what is being said.
It's up to the WG chair to set the meeting agenda, usually a few
weeks in advance. If you want something discussed at the meeting, be
sure to let the chair know about it. The agendas for all the WG
meetings are available in advance (see
http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the
meeting number), but many WG chairs are lax (if not totally
negligent) about turning them in.
The Secretariat only schedules WG meetings a few weeks in advance,
and the schedule often changes as little as a week before the first
day. If you are only coming for one WG meeting, you may have a hard
time booking your flight with such little notice, particularly if the
Working Group's meeting changes schedule. Be sure to keep track of
the current agenda so you can schedule flights and hotels. But, when
it comes down to it, you probably shouldn't be coming for just one WG
meeting. It's likely that your knowledge could be valuable in a few
WGs, assuming that you've read the drafts and RFCs for those groups.
Harris [Page 19]
INTERNET-DRAFT The Tao of IETF February 2001
If you're giving a presentation at a face-to-face meeting, you should
probably come with a few slides prepared. Projectors for laptop-based
presentations are available in all the meeting rooms. And here's a
tip for your slides: don't put your company's logo on every one,
even though it's common practice outside the IETF. The IETF frowns on
this kind of corporate advertising, and most presenters don't even
put their logo on their opening slide. The IETF is about technical
content, not company boosterism.
3.4 Working Group Mailing Lists
As previously mentioned, the IETF announcement and discussion mailing
lists are the central mailing lists for IETF activities. However,
there are many other mailing lists related to IETF work. For example,
every Working Group has its own discussion list. In addition, there
are some long-term technical debates which have been moved off of the
IETF list onto lists created specifically for those topics. It is
highly recommended that everybody follow the discussions on the
mailing lists of the Working Groups which they wish to attend. The
more work that is done on the mailing lists, the less work that will
need to be done at the meeting, leaving time for cross pollination
(i.e., attending Working Groups outside one's primary area of
interest in order to broaden one's perspective).
The mailing lists also provide a forum for those who wish to follow,
or contribute to, the Working Groups' efforts, but can't attend the
IETF meetings.
Most IETF discussion lists use Majordomo and have a "-request"
address which handles the administrative details of joining and
leaving the list. (See section 1.3 for more information on
Majordomo.) It is generally frowned upon when such administrivia
appears on the discussion mailing list.
Most IETF discussion lists are archived. That is, all of the messages
sent to the list are automatically stored on a host for anonymous FTP
access. Many such archives are listed online at
ftp://ftp.ietf.org/ietf-mail-archive/. If you don't find the list
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
Harris [Page 20]
INTERNET-DRAFT The Tao of IETF February 2001
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.
Harris [Page 21]
INTERNET-DRAFT The Tao of IETF February 2001
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 RFC Editor'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 RFC you're looking for, go to the IETF RFC pages,
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 ardous, 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 RFC starts 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 your draft to the IESG
6. Make any changes deemed necessary by the IESG (this might
include giving up on becoming a standard)
7. Wait for it to be published by the RFC Editor
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
Harris [Page 22]
INTERNET-DRAFT The Tao of IETF February 2001
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 RFC
1796, "Not All RFCs are Standards."
There are also three sub-series of RFCs, known as FYIs, BCPs, and
STDs. The For Your Information RFC sub-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.
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
Harris [Page 23]
INTERNET-DRAFT The Tao of IETF February 2001
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 RFC only 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; specificaions are published through the RFC
mechanism ... 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
RFC Editor when you create your I-Ds, it will simplify the RFC
Editor's work when your draft is published as an RFC. RFC 2223,
"Instructions to RFC Authors," describes the nroff formatting used by
the RFC Editor.
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 three documents:
- More important than just explaining formatting, RFC 2223 also
Harris [Page 24]
INTERNET-DRAFT The Tao of IETF February 2001
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 Hoffman wrote
might be named "draft-hoffman-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.
Harris [Page 25]
INTERNET-DRAFT The Tao of IETF February 2001
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 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 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
Harris [Page 26]
INTERNET-DRAFT The Tao of IETF February 2001
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 make sure it is
clear what is 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.
RFC 1123, "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 are 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 is
what BCP 14 tells you to do), so that the reader knows how you are
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
Harris [Page 27]
INTERNET-DRAFT The Tao of IETF February 2001
"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 described 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 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
Harris [Page 28]
INTERNET-DRAFT The Tao of IETF February 2001
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 some
protocol parameters, such as named options in the protocol. 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 the
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 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.
6.4.4 Security Considerations
One thing that's required in every RFC is a "Security Considerations"
section. The 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. Thus, 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.
Harris [Page 29]
INTERNET-DRAFT The Tao of IETF February 2001
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, 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).
6.5 Informational and Experimental RFCs
As we noted earlier, not all RFCs are standards. In fact, plenty of
important RFCs are not on 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, 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.
Harris [Page 30]
INTERNET-DRAFT The Tao of IETF February 2001
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; 2receive 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
Harris [Page 31]
INTERNET-DRAFT The Tao of IETF February 2001
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 IESG list of liaisons,
ftp://ftp.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 RFC was published. In both
cases, the press is not fully to blame for the problem, since they
Harris [Page 32]
INTERNET-DRAFT The Tao of IETF February 2001
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 these 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
Harris [Page 33]
INTERNET-DRAFT The Tao of IETF February 2001
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
iana@iana.org Internet Assigned Numbers Authority
ietf-info@ietf.org General queries about the IETF
ietf-rsvp@ietf.org Queries about meeting locations and fees
ietf-request@ietf.org Requests to join/leave IETF lists
ietf-web@ietf.org Web queries/comments
internet-drafts@ietf.org Internet Draft submissions and queries
proceedings@ietf.org IETF Proceedings Coordinator
rfc-ed@rfc-editor.org RFC Editor
ietf-secretariat@ietf.org Queries for the Secretariat
minutes@ietf.org Where to send Working Group minutes
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,
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 Used in the Tao
AD Area Director
BCP Best Current Practice
BOF Birds Of a Feather
FAQ Frequently Asked Question
FYI For Your Information (RFC)
IAB Internet Architecture Board
IANA Internet Assigned Numbers Authority
ICANN Internet Corporation for Assigned Names and Numbers,
Harris [Page 34]
INTERNET-DRAFT The Tao of IETF February 2001
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
RFC Request 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"
RFC 1123 "Requirements for Internet Hosts -- Application and Support"
RFC 1796 "Not All RFCs are Standards"
RFC 2223 "Instructions to RFC Authors"
"Considerations for Internet Drafts," www.ietf.org/ID-nits.html
"Guidelines to Authors of Internet-Drafts,"
ftp://ftp.ietf.org/ietf/1id-guidelines.txt
Editor Contact
Susan Harris
srh@merit.edu
Merit Network, Inc.
4251 Plymouth Road, Suite C
Ann Arbor, MI 48105
srh@merit.edu
Harris [Page 35]
INTERNET-DRAFT The Tao of IETF February 2001
Harris [Page 36]
