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). Please check with the Secretariat before placing
materials on the desk; the Secretariat has the right to remove
material that he or she feels is not appropriate.
If you rely on your laptop during the meeting, it is a good idea to
bring an extra battery. It is not always easy to find a spare outlet
in some meeting rooms, and using the wireless access can draw down
your battery faster than you might expect. If you are sitting near a
power-strip in a meeting room, expect to be asked to plug and unplug
for others around you. Many people bring an extension cord with
spare outlets, which is a good way to make friends with your neighbor
in a meeting. If you need an outlet adapter, you should try to buy
it in advance because the one you need is usually easier to find in
your home country.
5. 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
any good reason.) [BCP25], "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. Anyone can post to a WG mailing list,
although most lists require non-subscribers to have their postings
moderated. Each Working Group has one or two chairs.
More important, 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.
5.1. Working Group Chairs
The role of the WG chairs is described in both [BCP11] and [BCP25].
The IETF EDU team also offers special training for WG chairs on
Sunday afternoons preceding IETF.
As volunteer cat-herders, a chair’s first job is to determine the WG
consensus goals and milestones, keeping the charter up to date.
Next, often with the help of WG secretaries or document editors, the
chair must manage WG discussion, both on the list and by scheduling
meetings when appropriate. Sometimes discussions get stuck on
contentious points and the chair may need to steer people toward
productive interaction and then declare when rough consensus has been
met and the discussion is over. Sometimes chairs also manage
interactions with non-WG participants or the IESG, especially when a
WG document approaches publication. Chairs have responsibility for
the technical and non-technical quality of WG output. As you can
imagine given the mix of secretarial, interpersonal, and technical
demands, 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 attributed to what’s called "degenerative
Working Group syndrome".
There is an official distinction between WG drafts and independent
drafts, but in practice, sometimes there is not much procedural
difference. 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 WG leadership training
that usually happens on the Sunday preceding the IETF meeting. There
is also usually a WG chairs lunch mid-week during the meeting where
chair-specific topics are presented and discussed. If you’re
interested in what they hear there, take a look at the slides at
http://edu.ietf.org/.
5.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. Finally, WG meetings aren’t "drafting
sessions", as they are in some other standards bodies: in the IETF,
drafting is done elsewhere.
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. Sometimes consensus is determined by "humming" --
if you agree with a proposal, you hum when prompted by the chair; if
you disagree, you keep your silence. Newcomers find it quite
peculiar, but it works. It is up to the chair to decide when the
Working Group has reached rough consensus.
The lack of formal 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?) Rough consensus has been defined in many
ways; a simple version is that it means that strongly held objections
must be debated until most people are satisfied that these objections
are wrong.
Some Working Groups have complex documents or a complex set of
documents (or even both). Shaking all the bugs out of one or more
complex documents is a daunting task. In order to help relieve this
problem, some Working Groups use "issue trackers", which are online
lists of the open issues with the documents, the status of the issue,
proposed fixes, and so on. Using an issue tracker not only helps the
WG not to forget to do something important, it helps when someone
asks a question later about why something was done in a particular
fashion.
Another method that some Working Groups adopt is to have a Working
Group "secretary" to handle the juggling of the documents and the
changes. The secretary can run the issue tracker if there is one, or
can simply be in charge of watching that all of the decisions that
are made on the mailing list are reflected in newer versions of the
documents.
One thing you might find helpful, and possibly even entertaining,
during Working Group sessions is to follow the running commentary on
the Jabber room associated with that Working Group. The running
commentary is often used as the basis for the minutes of the meeting,
but it can also include jokes, sighs, and other extraneous chatter.
Jabber is a free, streaming XML technology mainly used for instant
messaging. You can find pointers to Jabber clients for many
platforms at http://www.jabber.org. The Jabber chatrooms have the
name of the Working Group followed by "@jabber.ietf.org". Those
rooms are, in fact, available year-round, not just during IETF
meetings, and some are used by active Working Group participants
during protocol development.
5.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 ahead of time. 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 are on the agenda at a face-to-face meeting, you should
probably come with a few slides prepared. But don’t come with a
tutorial; people are supposed to read the drafts in advance.
Projectors for laptop-based presentations are available in all the
meeting rooms.
And here’s a tip for your slides in WG or plenary presentations:
don’t put your company’s logo on every one, even though that is a
common practice outside the IETF. The IETF frowns on this kind of
corporate advertising (except for the meeting sponsor in the plenary
presentation), and most presenters don’t even put their logo on their
opening slide. The IETF is about technical content, not company
boosterism. Slides are often plain black and white for legibility,
with color used only when it really adds clarity. Again, the content
is the most important part of the slides, not how it’s presented.
5.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 you follow the discussions on
the mailing lists of the Working Groups that you 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. That’s why IETF procedures require all decisions to
be confirmed "on the list" and you will often hear a WG chair say,
"Let’s take it to the list" to close a discussion.
Many IETF discussion lists use either mailman or another list
manager, Majordomo. They usually have a "-request" address that
handles the administrative details of joining and leaving the list.
(See Section 3.3 for more information on mailman.) 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 HTTP or FTP access. Many such archives are listed online
at ftp://ftp.ietf.org/ietf-mail-archive/ or they are in a web-based
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!).
The Working Group charter listings at
http://www.ietf.org/html.charters/wg-dir.html are a useful source;
note that the page has links to old, concluded WGs.
Some WG lists apply size limits on messages, particularly to avoid
large documents or presentations landing in everyone’s mailbox. It
is well worth remembering that participants do not all have broadband
connections (and even those with broadband connections sometimes get
their mail on slow connections when they travel), so shorter messages
are greatly appreciated. Documents can be posted as Internet Drafts;
presentation material can be posted to a web site controlled by the
sender or sent personally to people who ask for it. Some WGs set up
special sites to hold these large documents so that senders can post
there first, then just send to the list the URL of the document.
5.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 (or even someplace mundane) three weeks later,
for example. Interim meetings require AD approval and need to be
announced at least one month in advance. Location and timing need to
allow fair access for all participants. Like regular IETF meetings,
someone needs to take notes and send them to
mailto:proceedings@ietf.org, and the group needs to take attendance.
Decisions tentatively made during an interim WG meeting still must be
ratified on the mailing list.
6. 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 Birds of a Feather (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 he or she thinks. 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 do 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, whereas 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.
7. New to the IETF and Coming to a Meeting? STOP HERE! (Temporarily)
If you’re new to the IETF and this is the only reference you plan to
read before coming to the meeting, stop here -- at least temporarily.
Then, on your flight home, read the rest of the Tao. By that time
you’ll be ready to get actively involved in the Working Groups that
interested you at the meeting, and the Tao will get you started on
your way.
If you’re planning to participate in the IETF remotely, through
reading email lists and the proceedings, read on!
8. 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.
8.1. Getting an RFC Published
One of the most common questions seasoned IETFers hear from newcomers
is, "How do I get an IETF standard published?" A much better
question is, "Should I write an IETF standard?" since the answer is
not always "yes." If you do decide to try to write a document that
becomes an IETF standard, be warned that the overall process may be
arduous, even if the individual steps are fairly straightforward.
Lots of people get through the process unscathed, though, and there’s
plenty of written guidance that helps authors emerge with their ego
more or less intact.
Every IETF standard is published as an RFC (a "Request for Comments,"
but everyone just calls them RFCs), and every RFC starts out as an
Internet Draft (often called an "I-D"). The basic steps for getting
something published as an IETF standard are as follows:
1. Publish the document as an Internet Draft.
2. Receive comments on the draft.
3. Edit your draft based on the comments.
4. Repeat steps 1 through 3 a few times.
5. Ask an Area Director to take the draft to the IESG (if it’s an
individual submission). If the draft is an official Working
Group product, the WG chair asks the AD to take it to the IESG.
6. Make any changes deemed necessary by the IESG (this might include
giving up on becoming a standard).
7. Wait for the document to be published by the RFC Editor.
A much more complete explanation of these steps is contained in
[BCP9], "The Internet Standards Process". Those who write drafts
that they hope will become IETF standards must read BCP 9 so that
they can follow the path of their document through the process. BCP
9 (and various other documents that update it) goes into great detail
on a topic that is very often misunderstood, even by seasoned IETF
participants: different types of RFCs go through different processes
and have different rankings. There are six kinds of RFCs:
o Proposed standards
o Draft standards
o Internet standards (sometimes called "full standards")
o Informational documents
o Experimental protocols
o Historic documents
Only the first three (proposed, draft, and full) are standards within
the IETF. A good summary of this can be found in the aptly titled
[RFC1796], "Not All RFCs Are Standards".
There are also three sub-series of RFCs, known as FYIs, BCPs, and
STDs. The For Your Information RFC sub-series was created to
document overviews and topics that are introductory or that appeal to
a broad audience; however, that series has not been added to in a
long time. Best Current Practice documents describe the application
of various technologies in the Internet. The STD RFC sub-series was
created to identify RFCs that do in fact specify Internet standards.
Some STDs are actually sets of more than one RFC, and the "standard"
designation applies to the whole set of documents.
8.2. Letting Go Gracefully
The biggest reason some people do not want their documents put on the
IETF standards track is that they must give up change control of the
protocol. That is, as soon as you propose that your protocol become
an IETF standard, you must fully relinquish control of the protocol.
If there is general agreement, parts of the protocol can be
completely changed, whole sections can be ripped out, new things can
be added, and the name can be changed.
Some authors find it very hard to give up control of their pet
protocol. If you are one of those people, don’t even think about
trying to get your protocol to become an IETF standard. On the other
hand, if your goal is the best standard possible with the widest
implementation, then you might find the IETF process to your liking.
Incidentally, the change control on Internet standards doesn’t end
when the protocol is put on the standards track. The protocol itself
can be changed later for a number of reasons, the most common of
which is that implementors discover a problem as they implement the
standard. These later changes are also under the control of the
IETF, not the editors of the standards document.
IETF standards exist so that people will use them to write Internet
programs that interoperate. They don’t exist to document the
(possibly wonderful) ideas of their authors, nor do they exist so
that a company can say, "We have an IETF standard". If a standards-
track 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.
8.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 [BCP9] says:
"An Internet Draft is NOT a means of ’publishing’ a specification;
specifications 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 he or she brags about
having published an Internet Draft; it takes no significant effort.
When you submit an Internet Draft, you give some publication rights
to the IETF. This is so that your Internet Draft is freely available
to everyone who wants to read and comment on it. The rights you do
and don’t give to the IETF are described in [BCP78], "IETF Rights in
Contributions".
There is a very useful checking tool at
http://tools.ietf.org/tools/idnits/idnits.pyht. Using this tool