Request for Comments: 4677 VPN Consortium
FYI: 17 S. Harris
Obsoletes: 3160 University of Michigan
Category: Informational September 2006
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 (2006).
Abstract
This document describes the inner workings of IETF meetings and
Working Groups, discusses organizations related to the IETF, and
introduces the standards process. It is not a formal IETF process
document but instead an informational overview.
Table of Contents
1. Introduction ....................................................4
2. Acknowledgements ................................................5
3. What Is the IETF? ...............................................5
3.1. Humble Beginnings ..........................................6
3.2. The Hierarchy ..............................................7
3.2.1. ISOC (Internet Society) .............................7
3.2.2. IESG (Internet Engineering Steering Group) ..........8
3.2.3. IAB (Internet Architecture Board) ..................10
3.2.4. IANA (Internet Assigned Numbers Authority) .........11
3.2.5. RFC Editor .........................................11
3.2.6. IETF Secretariat ...................................12
3.3. IETF Mailing Lists ........................................12
4. IETF Meetings ..................................................13
4.1. Registration ..............................................14
4.2. Take the Plunge and Stay All Week! ........................15
4.3. Newcomer Training .........................................16
4.4. Dress Code ................................................16
4.5. Seeing Spots Before Your Eyes .............................16
4.6. Terminal Room .............................................17
4.7. Meals and Other Delights ..................................17
4.8. Social Event ..............................................18
4.9. Agenda ....................................................18
4.10. EDU to the Rescue ........................................19
4.11. Where Do I Fit In? .......................................19
4.11.1. IS Managers .......................................19
4.11.2. Network Operators and ISPs ........................19
4.11.3. Networking Hardware and Software Vendors ..........20
4.11.4. Academics .........................................20
4.11.5. Computer Trade Press ..............................20
4.12. Proceedings ..............................................21
4.13. Other General Things .....................................21
5. Working Groups .................................................22
5.1. Working Group Chairs ......................................23
5.2. Getting Things Done in a Working Group ....................24
5.3. Preparing for Working Group Meetings ......................25
5.4. Working Group Mailing Lists ...............................26
5.5. Interim Working Group Meetings ............................27
6. BOFs ...........................................................27
7. New to the IETF and Coming to a Meeting? STOP HERE!
(Temporarily) ..................................................28
8. RFCs and Internet Drafts .......................................29
8.1. Getting an RFC Published ..................................29
8.2. Letting Go Gracefully .....................................30
8.3. Internet Drafts ...........................................31
8.3.1. Recommended Reading for Writers ....................32
8.3.2. Filenames and Other Matters ........................33
8.4. Standards-Track RFCs ......................................34
8.4.1. Telling It Like It Is -- Using MUST and SHOULD
and MAY ............................................35
8.4.2. Normative References in Standards ..................36
8.4.3. IANA Considerations ................................37
8.4.4. Security Considerations ............................37
8.4.5. Patents in IETF Standards ..........................37
8.5. Informational and Experimental RFCs .......................38
9. How to Contribute to the IETF ..................................39
9.1. What You Can Do ...........................................39
9.2. What Your Company Can Do ..................................40
10. IETF and the Outside World ....................................40
10.1. IETF and Other Standards Groups ..........................40
10.2. Press Coverage of the IETF ...............................41
11. Security Considerations .......................................42
Appendix A. Related Information ...................................43
A.1. Why "the Tao"? ............................................43
A.2. Useful Email Addresses ....................................43
A.3. Useful Documents and Files ................................44
A.4. Acronyms and Abbreviations Used in the Tao ................44
Appendix B. IETF Guiding Principles ...............................45
B.1. General ...................................................45
B.2. Management and Leadership .................................45
B.3. Process ...................................................46
B.4. Working Groups ............................................46
B.5. Documents .................................................47
Informative References ............................................48
1. Introduction
Since its early 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 email 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 document
provides the mundane bits of information that newcomers will need in
order to become active participants.
The IETF is always in a state of change. Although the principles in
this document are expected to remain largely the same over time,
practical details may well have changed by the time you read it; for
example, a web-based tool may have replaced an email address for
requesting some sort of action.
Many types of IETF documentation are mentioned in the Tao, from BCPs
to RFCs and FYIs and STDs. 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"; FYIs
provide topical and technical overviews that are introductory or
appeal to a broad audience; and STDs are RFCs identified as
"standards". See Section 8 for more information.
The acronyms and abbreviations used in this document are usually
expanded in place and are explained fully in Appendix A.
This document is intended to obsolete FYI 17, RFC 3160. See Section
3.2.5 for information on what it means for one RFC to obsolete
another.
2. 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 document are also much appreciated.
Paul Hoffman wrote significant portions of this revision and provided
encouragement, expertise, and much-needed guidance. Other
contributors include Brian Carpenter, Scott Bradner, Michael Patton,
Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault,
the IETF Secretariat, members of the User Services Working Group, and
members of the PESCI design team.
3. 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; see [BCP95], "A
Mission Statement for the IETF", for more detail.
Its mission includes the following:
o Identifying, and proposing solutions to, pressing operational and
technical problems in the Internet
o Specifying the development or usage of protocols and the near-term
architecture to solve such technical problems for the Internet
o Making recommendations to the Internet Engineering Steering Group
(IESG) regarding the standardization of protocols and protocol
usage in the Internet
o Facilitating technology transfer from the Internet Research Task
Force (IRTF) to the wider Internet community
o 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 3.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
[BCP11], "The Organizations Involved in the IETF Standards Process".
If you participate in the IETF and read only one BCP, this is the one
you should read.
In many ways, the IETF runs on the beliefs of its members. One of
the "founding beliefs" is embodied in an early quote about the IETF
from David Clark: "We reject kings, presidents and voting. We
believe in rough consensus and running code". Another early quote
that has become a commonly-held belief in the IETF comes from Jon
Postel: "Be conservative in what you send and liberal in what you
accept".
The IETF is really about its members. Because of the unrestrictive
membership policies, IETF members come from all over the world and
from many different parts of the Internet industry. See Section 4.11
for information about the ways that many people fit into the IETF.
One more thing that is important for newcomers: the IETF in no way
"runs the Internet", despite what some people mistakenly might say.
The IETF makes standards that are often adopted by Internet users,
but it does not control, or even patrol, the Internet. If your
interest in the IETF is because you want to be part of the overseers,
you may be badly disappointed by the IETF.
3.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 more than 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. About one in three 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 United States.
3.2. The Hierarchy
3.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
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-supported) heroes of the Internet.
Starting in spring 2005, the ISOC also became home base for the
IETF’s directly employed administrative staff. This is described in
more detail in [BCP101], "Structure of the IETF Administrative
Support Activity (IASA)". The staff initially includes only an
Administrative Director (IAD) who works full-time overseeing IETF
meeting planning, operational aspects of support services (the
secretariat, IANA (the Internet Assigned Numbers Authority), and the
RFC Editor, which are described later in this section), and the
budget. He or she (currently it’s a he) leads the IETF
Administrative Support Activity (IASA), which takes care of tasks
such as collecting meeting fees and paying invoices, and also
supports the tools for the work of IETF working groups, the IESG, the
IAB, and the IRTF (more about these later in this section).
As well as staff, the IASA comprises volunteers and ex officio
members from the ISOC and IETF leadership. The IASA and the IAD are
directed by the IETF Administrative Oversight Committee (IAOC), which
is selected by the IETF community. Here’s how all this looks:
Internet Society
|
IAOC
|
IASA
|
IAD
Neither the IAD nor the IAOC have any influence over IETF standards
development, which we turn to now.
3.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.
As its name suggests, its role is to set directions rather than to
give orders. The IESG ratifies or corrects the output from the
IETF’s Working Groups (WGs), 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 "the NomCom") and
are appointed for two years. The process for choosing the members of
the IESG is detailed in [BCP10], "IAB and IESG Selection,
Confirmation, and Recall Process: Operation of the Nominating and
Recall Committees".
The current areas and abbreviations are shown below.
Area Description
-----------------------------------------------------------------
Applications (APP) Protocols seen by user programs, such as
email 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
Real-time Delay-sensitive interpersonal
Applications and communications
Infrastructure (RAI)
Routing (RTG) Getting packets to their destinations
Security (SEC) Authentication and privacy
Transport (TSV) Special services for special packets
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 Area Directors
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 reviews each Internet Draft that is proposed to
become an RFC. Any AD may record a "DISCUSS" ballot position against
a draft if he or she has serious concerns. If these concerns cannot
be resolved by discussion, an override procedure is defined such that
at least two IESG members must express concerns before a draft can be
blocked from moving forward. These procedures 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 and
that an AD’s "pet peeve" cannot indefinitely block something.
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 eventually 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 scrutiny that the WG review gets from the
ADs.
The IETF is run by rough consensus, and it is the IESG that judges
whether a WG has come up with a result that has community consensus.
(See Section 5.2 for more information on WG 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.
3.2.3. IAB (Internet Architecture Board)
The IAB is responsible for keeping an eye on the "big picture" of the
Internet, and it 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 it brings these
topics to the attention of people it thinks should know about them.
The IAB web site is at http://www.iab.org/.
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:
o Approves NomCom’s IESG nominations
o Acts as the appeals board for appeals against IESG actions
o Appoints and oversees the RFC Editor
o Approves the appointment of the IANA
o Acts as an advisory body to ISOC
o 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 ISOC Board of Trustees.
3.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.
Ten years ago, no one would have expected to 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
that 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.
3.2.5. RFC Editor
The RFC Editor edits, formats, and publishes Internet Drafts as RFCs,