Request for Comments: 3160 Merit Network
FYI: 17 August 2001
Obsoletes: 1718
Category: Informational
The Tao of IETF - A Novice's Guide to the Internet Engineering
Task Force
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
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
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 3
1. What Is the IETF? . . . . . . . . . . . . . . . . . . . . . 4
1.1 Humble Beginnings. . . . . . . . . . . . . . . . . . . . 5
1.2 The Hierarchy . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 IESG . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 IAB. . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 RFCEditor . . . . . . . . . . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . 12
2.3 Dress Code. . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . . 13
2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . . 13
2.6 Meals and Other Delights. . . . . . . . . . . . . . . . 14
2.7 Social Event. . . . . . . . . . . . . . . . . . . . . . 14
2.8 Agenda. . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Where Do I Fit In?. . . . . . . . . . . . . . . . . . . 15
2.9.1 IS Managers. . . . . . . . . . . . . . . . . . . 15
2.9.2 Network Operators and ISPs . . . . . . . . . . . 15
2.9.3 Networking Hardware and Software Vendors . . . . 15
2.9.4 Academics . . . . . . . . . . . . . . . . . . . 16
2.9.5 Computer Trade Press . . . . . . . . . . . . . . 16
2.10 Proceedings. . . . . . . . . . . . . . . . . . . . . . 16
2.11 Other General Things . . . . . . . . . . . . . . . . . 17
3. Working Groups. . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Working Group Chairs . . . . . . . . . . . . . . . . . .18
3.2 Getting Things Done in a Working Group. . . . . . . . . 19
3.3 Preparing for Working Group Meetings . . . . . . . . 19
3.4 Working Group Mailing Lists . . . . . . . . . . . . . 20
3.5 Interim Working Group Meetings . . . . . . . . . . . . 21
4. BOFs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. New to the IETF? STOP HERE! (Temporarily). . . . . . . . . 22
6. RFCs and Internet Drafts . . . . . . . . . . . . . . . . . 22
6.1 Getting a Standard Published . . . . . . . . . . . . . 22
6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . . 24
6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . . 24
6.3.1 Recommended Reading for Writers . . . . . . . . . 25
6.3.2 Filenames and Other Matters . . . . . . . . . . . 26
6.4 Standards-Track RFCs . . . . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . 30
6.5 Informational and Experimental RFCs . . . . . . . . . . 31
7. How to Contribute to the IETF -- What You Can Do . . . . . . 31
7.1 What Your Company Can Do . . . . . . . . . . . . . . . 32
8. IETF and the Outside World . . . . . . . . . . . . . . . . . 33
8.1 IETF and Other Standards Groups . . . . . . . . . . . . 33
8.2 Press Coverage of the IETF. . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . . 35
9.3 Useful Documents and Files. . . . . . . . . . . . . . . 35
9.4 Acronyms and Abbreviations Used in the Tao . . . . . . 36
9.5 Documents Cited in the Tao . . . . . . . . . . . . . . 36
Security Considerations . . . . . . . . . . . . . . . . . . . . 37
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 37
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 38
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 and FYIs. (BCPs make recommendations for Best Current
Practices in the Internet; RFCs are the IETF's main technical
documentation series, politely known as "Requests for Comments;" and
FYIs provide topical and technical overviews that are introductory or
appeal to a broad audience. See Section 6 for more information.)
The acronyms and abbreviations 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.
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
should read.
1.1 Humble Beginnings
The first IETF meeting was held in January, 1986, at Linkabit in San
Diego, with 21 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 under-funded) heroes of the Internet.
1.2.2 IESG (Internet Engineering Steering Group)
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 Operational aspects, network monitoring,
Management (OPS) and configuration
- 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 discusses each Internet Draft that is proposed
to become an RFC. At least two IESG members must express concerns
before a draft can be blocked from moving forward. These checks help
ensure 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.
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 Working
Groups in all areas. For instance, the result of one WG might clash
with a technology developed in a different Working Group. 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 RFCEditor
- 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 IAB has designated the IANA organization to perform these tasks,
and the IANA's activities are financially supported 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 IETF is generally no
longer involved in the IANA's domain name and IP address assignment
functions, which 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 by leaps and bounds, and he did a fine job of
it until his untimely death in 1998.
1.2.5 RFCEditor
The RFCEditor 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
http://www.rfc-editor.org). Once an RFCis published, it is never
revised. If the standard it describes changes, the standard will be
re-published in another RFCthat "obsoletes" the first.
One of the most popular misconceptions in the IETF community is that
the role of the RFCEditor is performed by IANA. In fact, the RFC
Editor is a separate job, although both the RFCEditor and IANA
involved the same people for many years. The IAB approves the
organization that will act as RFCEditor and the RFCEditor's general
policy. The RFCEditor 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 RFCannouncements,
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:
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," RFC3005. 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 mean you'll be automatically added 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 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 50 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.
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
possible. 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.
To pre-register, you must submit your registration on the Web. You
may pre-register and pre-pay, pre-register and return to the Web site
later to pay with a credit card, pre-register and pay on-site at the
meeting, or register and pay on-site. To get a lower registration
fee, you must pay by the early registration deadline (about one week
before the meeting). The registration fee covers all of the week's
meetings, the Sunday evening reception (cash bar), daily continental
breakfasts, and afternoon coffee breaks.
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 (ietf-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 much useful information, including
a general orientation sheet, 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.
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 what's in the attendee
packets, what all the dots on name tags mean, the structure of the
IETF, and many other essential and enlightening topics for new
IETFers.
Immediately following the Newcomers' Orientation is the IETF
Standards Process Orientation. This session demystifies much of the
standards process by explaining what stages a document has to pass
through on its way to becoming a standard, and what has to be done to
advance to the next stage. The Standards Process Orientation 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 - Host group
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 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
Another of the most important things organized and managed by the
host 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,
updated, to the IETF announcement list three times prior to the
meeting, and is also available on the web. The agenda for the 50th
IETF, for example, is at http://www.ietf.org/meetings/agenda_50.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 are also shown on the
agenda. Room assignments can change as the agenda changes. 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.
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
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, so it's
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 up shop during IETF
meeting weeks so everyone can 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.
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 prepared a special section of the Tao just for 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, on CD, and in print. Be sure
to look 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!
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, descriptions 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
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 Working Group has one or two chairs.
More importantly, each WG has a charter that the WG is supposed to
follow. The charter states the scope of discussion for the Working
Group, 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 Working Groups 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 Working Group 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 Working
Group 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 Working Group 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
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.
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 we mentioned earlier, 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 that 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 that 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