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
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.
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.
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.
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,
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 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
organization that will act as RFC Editor and the RFC Editor's general
policy. The RFC Editor is funded by IASA and can be contacted by
email at mailto:rfc-editor@rfc-editor.org.
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 helping the IESG do its work. It provides various tools
for use by the community and the IESG. The IETF Secretariat is under
contract to IASA, which in turn is financially supported by the fees
of the face-to-face meetings.
Anyone who plans to attend an IETF meeting should join the IETF
announcement mailing list, mailto:ietf-announce@ietf.org. This is
where all of the meeting information, RFC announcements, and IESG
Protocol Actions and Last Calls are posted. People who would like to
"get technical" may also join the IETF general 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). Another mailing list, mailto:i-d-
announce@ietf.org, announces each new version of every Internet Draft
as it is published.
Subscriptions to these and other IETF-run mailing lists are handled
by a program called "mailman". Mailman can be somewhat finicky about
the format of subscription messages, and sometimes interacts poorly
with email programs that make all email messages into HTML files.
Mailman 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
mailto: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
<mailto: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 mailman 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 email 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 all 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 [BCP45], "IETF Discussion List Charter". It
is a good idea to read the whole RFC (it's short!) before posting to
the IETF discussion list. Actually, the list does have two
"sergeants at arms" who keep an eye open for inappropriate postings,
and there is a process for banning persistent offenders from the
list, but fortunately this is extremely rare.
Only the Secretariat and certain IETF office holders can approve
messages sent to the announcement list, although those messages can
come from a variety of people.
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.
