Internet Draft                                    Editor:
draft-ietf-uswg-tao-00.txt                        Susan Harris
July 2, 2000                                      Merit Network, Inc.
Expires in six months

                            The Tao of IETF

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Abstract

In recent years, the 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 wasn't
very difficult 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.

Many IETF participants don't go to the face-to-face meetings. Instead,
they are active on the mailing list of the IETF Working Groups. The
methods and mechanisms of Working Groups are often difficult for
newcomers to comprehend.

. Introduction

The purpose of this For Your Information (FYI) document is to explain to
the 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. This FYI will also provide the
mundane bits of information which everyone who attends an IETF meeting
or contributes to Working Group mailing lists should know.

Many acronyms are used in this document. The acronyms are usually
expanded in place, and there is an full list (with explanations) in
Appendix B.

[[ Why this document is called "Tao" ]]

1.1 Acknowledgements

The original version of this document, published in 1994, was written by
Gary Malkin. The outline for the revised document was created by Susan
Harris.

Significant portions of this new document were written by Paul Hoffman.
Other contributors include Scott Bradner, [[ more people added here as
they contribute significant ideas or text ]].

. What Is the IETF?

One of the facts about the IETF that bothers many newcomers is that the
IETF doesn't exist. Well, it does exist as a collection of happenings
and people, but it doesn't legally exist. There's no corporation, no
board of directors, no members, and no dues. It is really just a bunch
of people who agree that it exists and are willing to work to be sure
that it exists well. Pretty nifty trick, eh?

The Internet Engineering Task Force is a loosely self-organized group of
people who make technical and other contributions to the engineering and
evolution of the Internet and its technologies. It is the principal
body engaged in the development of new Internet standard specifications.

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 who 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 the IETF Mailing
Lists section). 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.

2.1 Humble Beginnings

The 1st IETF meeting was held in January, 1986 at Linkabit in San Diego
with 15 attendees. The 4th IETF, held at SRI in Menlo Park in October,
1986, was the first at which 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
the 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.

2.2 The Hierarchy

2.2.1 ISOC (Internet Society)

The Internet Society is the international non-profit 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 members don't even know about it.
ISOC accepts the IETF-defined standards process, they provide insurance
coverage for many of the people in the IETF process, and they give a
public relations channel for the times that one of the "I" groups wants
to say something to the press. The ISOC is one of the major unsung (and
underfunded) heroes of the Internet.

2.2.2 Working Groups (WGs)

The vast majority IETF's work is done in many "Working Groups"; at the
time of this writing, there are about 115 different WGs. (The term
"Working Group" is often seen capitalized, but probably not for a very
good reason.) BCP 25, "IETF Working Group Guidelines and Procedures", is
an excellent resource for anyone participating in WG discussions.

A WG is really just a mailing list with a bit of adult supervision. You
"join" the WG by subscribing to the mailing list; all mailing lists are
open to anyone. Some IETF WG mailing lists only let subscribers to the
mailing list post to the mailing list, while others let anyone post.
Each WG has one or two chairpeople.

More importantly, each WG has a charter that the WG is supposed to
follow. The charter states what the scope of the discussion for the WG
is, as well as what are the goals of the WG. The WG's mailing list and
face-to-face meetings are supposed to focus on just what is in the
charter, and not to wander off on other "interesting" topics. Of course,
looking a bit outside the scope of the WG is occasionally useful, but
the large majority of the discussion should be on the topics listed in
the charter. In fact, some WG charters actually specify what the WG will
not do, particularly if there were some attractive but nebulous topics
brought up during the drafting of the charter. The list of all WG
charters makes interesting reading for folks who want to know what the
different WGs are supposed to be doing.

2.2.2.1 WG Chairs

The role of the WG chairs is described in both BCP11 and BCP 25.
Basically, their job is to keep the discussion moving forwards towards
the milestones in the WG charter, which is usually publication of one or
more RFCs. They are not meant to be taskmasters, but are responsible for
assuring positive forward motion and preventing random wandering.

As you can imagine, some WG chairs are much better at their jobs than
others. When a WG has fulfilled its charter, it is supposed to cease
operations. (Most WG mailing lists continue on after a WG is closed,
still discussing the same topics as the WG did.) In the IETF, it is a
mark of success that the WG closes up because it fulfilled its charter.
This is one of the aspects of the IETF that newcomers who have
experience with other standards bodies have a hard time understanding.
However, some WG chairs never manage to get their WG to finish, or keep
adding new tasks to the charter so that the WG drags on for many years.
The output of these aging WGs is often not nearly as useful as the
earlier products, and the messy results are sometimes called
"degenerative Working Group syndrome".

One important role of the chair is to decide which Internet Drafts get
published as "official" Working Group drafts, and which don't. In
practice, there is actually not much procedural difference between WG
drafts and independent drafts; for example, many WG mailing lists also
discuss independent drafts (at the discretion of the WG chair).
Procedures for Internet Drafts are covered in much more detail later in
this document.

WG chairs are strongly advised to go to the new chairs' training lunch
the first day of the IETF meeting. If you're interested in what they
hear there, you may find the slides of the WG chairs training to be
useful.

2.2.2.2 Getting Things Done in the WG

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 due to someone who could not attend the meeting
pointing 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 WG to WG. 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 it is impossible to count the participants?)

2.2.3 IESG (Internet Engineering Steering Group)

The IESG is pretty much the leadership of the IETF. However, they don't
do much direct leadership, such as the kind you will find in many other
standards organizations. The basic purposes of the IESG are to ratify or
correct the output from the IETF's Working Groups, to get WGs started
and finished, and to make 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".
Basically, Nomcom is a randomly selected voluntary committee with the
task of suggesting people to fill open slots on the IESG. Open slots
usually occur when a serving AD's term expires. (Nomcom does the same
thing for the IAB.)

The current areas are:

- Applications: protocols seen by user programs, such as email and the Web

- General: catch-all for WGs that don't fit in other areas (which is very few)

- Internet: different ways of moving IP packets and DNS information

- Operations and Management: administration and monitoring

- Routing: getting packets to their destinations

- Security: authentication and privacy

- Transport: special services for special packets

- User Services: support for end users and user support organizations

Because the IESG has a great deal of influence in the decision to help
or to prevent Internet Drafts from becoming 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.

The ADs for a particular area are expected to know more about the WGs in
that area than anyone else. On the other hand, the entire IESG votes on
each Internet Draft that is becoming an RFC, and it only takes two IESG
members to block a draft from moving forwards. The purpose of this is to
make sure that an AD's "pet project" doesn't make it onto 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 see 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 their high work load, the IESG usually moves in a
reactive fashion. They approve most WG requests for Internet Drafts to
become RFCs, and usually only step in when something has gone very
wrong. Another way to think about this is that the ADs are hired 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 is 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 is not really consensus in the IETF
as a whole, that is, among all of the WGs in all areas. For instance,
the result of one WG might clash with a technology developed in a
different WG. An important job of the IESG 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.

2.2.4 IAB (Internet Architecture Board)

The IAB is responsible for looking at the "big picture" of the Internet.
They are the ISOC's technical advisory group, and they often contribute
to the IETF's process by focusing on topics that span many WGs and many
areas.

Like the IESG, the IAB is selected for multi-year positions by Nomcom,
as described in BCP 10. In an interesting twist on normal rules of
hierarchy, the IAB is actually the body that seats the IESG. That is,
Nomcom gives its nominations to the IAB, who then decides whether or not
to accept the nominations. There has never been a case where the IAB
didn't support the Nomcom's nominations.

Probably the most important job done by the IAB is to act as liaison
with groups outside the IETF that affect the IETF standards process.
These groups include the RFC Editor and the IANA, whose contracts are
both with the IAB. The IAB also has liaisons with other standards
bodies, such as the ITU (International Telecommunication Union).

The IAB is also in the unenviable position of being the court of appeal
when someone complains that the IETF process has failed. This means that
someone who feels that the IESG or Nomcom has done something wrong takes
their complaint to the IAB. The appeals process is mentioned later in
this document.

2.2.5 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. IANA is
chartered by the IAB and these days is paid for by the ISOC.

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. The domain name and IP address assignment functions are no
longer part of the IETF's IANA.

Even though being a registrar may not sound interesting, many IETF
participants will testify to how important IANA has been for the
Internet. Having a stable, long-term repository run by careful and
conservative operators makes it much easier for people to experiment
without worrying about messing things up. IANA's founder, Jon Postel,
was heavily relied upon to keep things in order while the Internet kept
growing in leaps and bounds, and he did a fine job of it.

2.2.6 RFC Editor

At last, a group that doesn't have an acronym starting with "I"! The
main role of the RFC Editor is to decide which Internet Drafts become
RFCs. An important secondary role is to format the RFCs in a consistent
fashion, and to be sure that there is at least one definitive repository
for all RFCs. The RFC editor does essentially no editing on documents,
including not doing any spelling correction. (Getting an RFC published
is described later in this document.)

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 have always been
the same people. Both are contracted by the IAB, and both are paid for
by ISOC. The RFC Editor can be contacted by email at
rfc-ed@rfc-editor.org.

2.2.7 IETF Secretariat

There are, in fact, a few people who are paid to maintain the IETF. The
IETF Secretariat does day-to-day logistical support, which mainly means
coordinating the 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, and for helping the IESG do its work. The IETF
Secretariat is financially supported by the fees of the face-to-face
meetings.

. 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 get a fair amount
of mixing between the WGs and the areas. The cost of the meetings is
paid by the people attending the meetings and by the corporate host for
each meeting, although ISOC kicks in additional funds for things like
the MBONE simulcast of the meetings.

For many people, IETF meetings are a breath of fresh air when compared
to the standard computer industry conferences. There is no exposition
hall, no 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 2000 attendees. There have been over 45 IETF meetings so far, and
future meeting sites are usually announced at least three months in
advance.

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 email and reading
the web pages during presentations they find uninteresting.

3.1 Registration

All meeting announcements are sent to the IETF announcement mailing
list. Within the IETF meeting announcement is a link to a registration
form and complete instructions for registering, including, of course,
the cost. The Secretariat highly recommends that attendees preregister.
Early registration carries a lower registration fee. As the size of the
meetings has grown, so has the length of the lines at the registration
desk. There are two lines: "paid" (which moves very quickly), and "not
paid" (which moves slowly).

Registration is open all week. However, the Secretariat highly
recommends that attendees arrive for early registration, usually
beginning around noon on the Sunday before the first plenary meeting.
Sunday evening, there is a reception at which people can get a bite to
eat.

Registered attendees (and there isn't any other kind) receive a
registration packet. It contains a general orientation sheet, the
at-a-glance sheet, a list of working group acronyms, the most recent
agenda and a name tag. The at-a-glance is a very important reference and
is used throughout the week. It contains working group and BOF room
assignments and a map of room locations. Attendees who prepaid will also
find their receipt in their packet.

3.2 Newcomers' Orientation

Newcomers are encouraged to attend the IETF Newcomers' Orientation. As
the name implies, it is an orientation for first-time attendees to IETF
meetings. The orientation is organized and conducted by the IETF
Secretariat and is intended to provide useful introductory information.

The orientation is typically about an hour long and covers a number of
topics: what's in the attendee packets, what all the dots on name tags
mean and how to read the at-a-glance. There is also discussion about the
structure of the IETF and the Internet standards process. There is ample
time at the end for questions. The Secretariat also provides handouts
which include an overview of the IETF, a list of important files
available on-line and hard copies of the slides of the "structure and
standards" presentation.

The orientation is held on Sunday afternoon before the registration
reception. However, attending the orientation does NOT mean you can go
to the reception early!

3.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!).


3.4 Seeing Spots Before Your Eyes

Some of the people at the IETF will have a little colored dot on their
name tag. A few people have more than one. These dots identify people
who are silly enough to volunteer to do a lot of extra work. The colors
have the following meanings:

    blue   - working group/BOF chair
    green  - local Host
    red    - IAB member
    yellow - IESG member

Local hosts are the people who can answer questions about the terminal
room, restaurants and points of interest in the area.

Some people have gold stars on their name tags. The stars indicate that
those people chaired working groups or BOFs in the IETF area which
submitted all of its working group/BOF minutes and area report from the
previous meeting first. The stars are the Secretariat's way of saying
"thank you" for providing the necessary information quickly.

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.

In addition, members of the Secretariat wear blue tinted name badges so
they can be spotted at a distance.

To make life simpler for the Secretariat, registration packets are also
coded with little colored dots. These are only for Secretariat use, so
nobody else needs to worry about them. Please, don't peel them off your
packet and put them on your name tag.

3.5 Terminal Room

One of the most important (depending on your point of view) things the
local host does is provide Internet access to the meeting attendees. In
general, the 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 which 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.

3.6 Social Event

Another of the most important things organized and managed by the local
hosts is the IETF social event. The social event has become something of
a tradition at the IETF meetings. It has been immortalized by Marshal T.
Rose with his reference to "many fine lunches and dinners" [ROSE], and
by Claudio and Julia Topolcic with their rendition of "Nerds in
Paradise" on a pink T-shirt.

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. The social event is
designed to give people a chance to meet on a social, rather than
technical, level.

3.7 Agenda

The agenda for the IETF meetings is a very fluid thing. It is sent, in
various forms, to the IETF announcement list three times prior to the
meeting. 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 printers.

The Secretariat will announce agenda changes during the morning plenary
sessions. Changes will also be posted on the bulletin board near the
IETF registration desk (not the hotel registration desk).

Assignments for breakout rooms (where the working groups and BOFs meet)
and a map showing the room locations make up the at-a-glance sheet
(included in the registration packets). Room assignments are as flexible
as the agenda. Some working groups meet multiple times during a meeting
and every attempt is made to have a working group meet in the same room
each session. Room assignment changes are not necessarily permanent for
the week. Always check the at-a-glance first, then the bulletin board.
When in doubt, check with a member of the Secretariat at the
registration desk.

3.8 Other General Things

The opening plenary on Monday morning is often the most heavily attended
session. It is where important introductory remarks are made, so people
are encouraged to attend.

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.

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 sessions in particular, are not places for
vendors to try to sell their wares. People can certainly answer
questions about their company and its products, but bear in mind that
the IETF is not a trade show. This does not preclude people from
recouping costs for IETF related t-shirts, buttons and pocket
protectors.

There is always a "materials distribution table" near the registration
desk. This desk is used to make appropriate information available to the
attendees (e.g., copies of something discussed in a working group
session, description of on-line 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.

[[ Need to be placed somewhere in this section:
- Before the Meeting
     - Upcoming meetings listed on Web
     - Hotel and registration announced 2 months before unless held
       outside US, then earlier.
     - Announcement sent to list the same day Web page goes up.
     - Registration covers whole meeting
     - Registration is secure via Web, databases not stored online
       and are destroyed at end of meeting, IETF doesn't sell
       mailing lists.
     - Proceedings and drafts available on CD
]]

. WG 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 before the meeting. 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 that you can understand what is
being said.

It is up to the WG chair to set the agenda for the meeting, usually a
few weeks in advance of the meeting. 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, but many WG chairs are lax (if
not totally negligent) about turning them in.

The WG meetings are scheduled only 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 WG's meeting
changes schedule. You should keep track of the current agenda so you can
schedule flights and hotels. But, you should probably not 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
WGs.

If you are giving a presentation at a face-to-face meeting, you should
probably come with a few slides prepared. Until recently, almost all
presentations were done on transparencies; recent meetings have had
projectors for laptop-based presentations. The IETF Secretariat has said
that there will be projectors at all future meetings. You should
definitely avoid a practice that is common outside the IETF, which is
putting your company's logo on every slide. 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.

. 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 due to individuals interested in the
topic.

A BOF meeting must be approved by the Area Director in the relevant area
before it can be scheduled. If you think you really need a new WG, you
should first approach an AD informally with your proposal. If he or she
thinks it's good (or at least reasonable), they will let you know. You
should then request a meeting slot at the next face-to-face meeting. You
do not need to wait for that meeting before getting work done, such as
setting up a mailing list and start discussing a charter.

BOF meetings have a very different tone than WG meetings. The purpose of
a BOF is to make sure that a good charter with good milestones can be
created, and that there are enough people willing to do the work needed
in order to create standards. Some BOFs have Internet Drafts already in
process, while others start from scratch. An advantage of having a draft
before the BOF is to help focus the discussion; on the other hand,
having a draft might tend to limit what the other folks in the BOF want
to do in the charter. It is important to remember that most BOFs happen
in order to get support for an eventual Working Group, not to get
support for a particular document.

Many BOFs do not 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 would not end up being a
standard, such as if the document authors do not really want to
relinquish change control to a WG. Only two BOFs on a particular subject
can take place; either a WG has to form, or the topic should be dropped.

There is a second kind of BOF that happens as often, if not more often,
than the ones described above. A "bar BOF" is a very unofficial
gathering of some people to talk about some topic for some period of
time. The number of people, the breadth of the topic, and the expected
length of time usually expand as the meeting happens. Bar BOFs often
happen in many different places around an IETF meeting, such as
restaurants, coffee shops, and (if we are so lucky) pools.

. Mailing lists

Anyone who plans to attend an IETF meeting should join the IETF
announcement mailing list. This is where all of the meeting information,
Internet-Draft and RFC announcements, and IESG Protocol Actions and Last
Calls are posted. To join the IETF announcement list, send a request to:

         ietf-announce-request@ietf.org

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 (most working groups have their own mailing lists
for discussions related to their work). To join the IETF discussion
list, send a request to:

         ietf-request@ietf.org

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.
Only the Secretariat can send messages to the announcement list.

Even though the IETF mailing lists "represent" the IETF membership at
large, it is important to note that attending an IETF meeting does not
automatically include addition to either mailing list.

As previously mentioned, the IETF announcement and discussion mailing
lists are the central mailing lists for IETF activities. However, there
are many other mailing lists related to IETF work. For example, every
working group has its own discussion list. In addition, there are some
long-term technical debates which have been moved off of the IETF list
onto lists created specifically for those topics. It is highly
recommended that everybody follow the discussions on the mailing lists
of the working groups which they wish to attend. The more work that is
done on the mailing lists, the less work that will need to be done at
the meeting, leaving time for cross pollination (i.e., attending working
groups outside one's primary area of interest in order to broaden one's
perspective).

The mailing lists also provide a forum for those who wish to follow, or
contribute to, the working groups' efforts, but cannot attend the IETF
meetings.

Most IETF discussion lists have a "-request" address which handles the
administrative details of joining and leaving the list. 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. To find out where a particular list is archived, send a message
to the list's "-request" address, NOT to the list itself.

. Useful E-mail Addresses

There are some important IETF e-mail addresses with which everyone
should be familiar. They are all located at "ietf.org" (e.g.,
"ietf-info@ietf.org"). To personalize things, the names of the
Secretariat staff who currently respond to the messages are given for
each address.

[[ These need to be checked and maybe pruned. Few of the names are
at all current. ]]

- ietf-info         general queries about the IETF - Cynthia Clark,
                     Debra Legare, John Stewart, and Megan Walnut

- ietf-rsvp         queries about meeting locations and fees,
                     e-mailed registration forms - Debra Legare

- proceedings       queries about ordering hard copies of previous
                     proceedings, and general questions about on-line
                     proceedings - Debra Legare and John Stewart

- ietf-request      requests to join/leave IETF lists - Cynthia Clark

- internet-drafts   Internet-Draft submissions and queries - Cynthia
                     Clark and John Stewart

- iesg-secretary    John Stewart

- ietf-secretariat  Steve Coya

. Useful documents and files.

[[ TBD. Will include:
- Filenames and URLs for:
  - agenda
  - mtg-at-a-glance
  - mtg-rsvp
  ....
  - wg-summary, etc.
    - Mirror sites
]]

. RFCs and Internet Drafts

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 attempt to write a document that becomes an
IETF standard, the process is not all that hard, and there is plenty of
written guidance on how to do it.

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:

.      Publish the document as an Internet Draft

.      Receive comments on the draft

.      Edit your draft based on the comments

.      Repeat steps 1 through 3 a few times

.      Ask an Area Director to take your draft to the IESG

.      Make any changes deemed necessary by the IESG (this might include
giving up on becoming a standard)

.      Wait for it to be published by the RFC Editor

A much more complete explanation of the steps is contained in BCP 9,
"The Internet Standards Process". Anyone who writes a draft that they
hope will become an IETF standard must read BCP 9 so that they can
follow the path of their document through the process. BCP 9 goes into
great detail on a topic that is very often misunderstood, even by
seasoned IETF participants: different types of RFCs go through different
processes and have different statuses. There are six kinds of RFCs:

- proposed standards

- draft standards

- Internet standards (sometimes called "full standards")

- experimental protocols

- informational documents

- historic standards

Only the first three (proposed, draft, and full) are standards within
the IETF. A good summary of this can be found in the aptly-titled RFC
1796, "Not All RFCs are Standards".

9.1 Change Control for Internet Standards

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
standards track), it was probably a mistake to put it on the standards
track in the first place.

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 people find it very scary 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 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.

9.2 Internet Drafts

First thing first. Every document that ends up in the RFC repository
starts as an Internet Draft. Internet Drafts are tentative documents
that help bring comments to the author about something that might become
an RFC. In order to remind folks of their tentativeness, Internet-Drafts
are automatically removed from the on-line directories after six months.
The are most definitely not standards or even specifications. As BCP 9
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 they brag about having
published an Internet draft; it takes no significant effort.

An I-D should have approximately the same format as an RFC. Contrary to
many people's beliefs, an I-D does not need to look exactly like an RFC,
but if you can use the same formatting procedures used by the RFC Editor
when you create your I-Ds, it will simplify the RFC Editor's work when
your draft is published as an RFC. RFC 2223, "Instructions to RFC
Authors", describes the nroff formatting used by the RFC Editor.

Before you create the first draft of your Internet Draft, you should
read three documents.

- More important than just explaining formatting, RFC 2223 also explains
what needs to be in an Internet Draft before it can become an RFC. This
document describes all the sections and notices that will need to be in
your document before it becomes an RFC, and it is good to have them
there from the beginning so that readers aren't surprised when you put
them in later versions.

- BCP 22, "Guide for Internet Standards Writers", gives guidance about
how to write standards that will lead to interoperability. For instance,
it goes into choosing how many protocol options to have, response to
out-of-spec behavior, how to show state diagrams, and so on.

- The online "Guidelines to Authors of Internet-Drafts" has up-to-date
information about the process for turning in Internet Drafts, as well as
the most current boilerplate information that has to be included in each
Internet Draft.

When you are ready to turn in your Internet Draft, you send it to
Internet Drafts editor at internet-drafts@ietf.org. There is a real
person at the other end of this mail address. That person's job is to
make sure that you included the minimum things you needed for the
Internet Draft to be published.

When you submit the first version of the draft, the draft editor gives
the file name for the draft. If the draft is an official Working Group
product, the name will start with "draft-ietf-" followed by the
designation of the WG, followed by a descriptive word or two, followed
by "00.txt"; for example, a draft in the S/MIME WG about creating keys
might be named "draft-ietf-smime-keying-00.txt". If it is not the
product of a Working Group, the name will start with "draft-" and the
last name of one of the authors followed by a descriptive word or two,
followed by "00.txt"; for example, a draft that I wrote might be named
"draft-hoffman-keying-00.txt". You are welcome to suggest names;
however, it is up to the Internet Drafts editor (and, if it is an
official WG draft, the WG chair) to come up with the file name.

After the first edition of a draft, the number in the file name in
incremented; for instance, the second edition of the S/MIME draft named
above would be "draft-ietf-smime-keying-01.txt". Note that there are
cases where the file name changed after the first version, such as when
a personal effort is pulled into a Working Group.

When you think you are finished with the draft process and are ready to
request that the draft become an RFC, you should definitely read
Considerations for Internet Drafts, which is prepared by the IESG. In
fact, you should probably read that document well before you are
finished, so that you don't have to make a bunch of last-minute changes.

9.3 Standards-Track RFCs

The procedure for creating and advancing a standard is described in BCP
. After an Internet Draft has been sufficiently discussed and there is
rough consensus that what it says would be a useful standard, it is
presented to the IESG for consideration. If the draft is an official WG
draft, the WG chair sends it to the appropriate Area Director after it
has gone through Working Group last call. If the draft is an individual
submission, the draft's author or editor submits it to the appropriate
Area Director. BCP 9 also describes the appeals process for people who
feel that a Working Group chair, an AD, or the IESG has made a wrong
decision in considering the creation or advancement of a standard.

After it is submitted to the IESG, the IESG announces an IETF-wide last
call. This helps get the attention of people who weren't following the
progress of the draft, and can sometimes cause further changes to the
draft. It is also a time where people in the WG who feel that they
weren't heard can make their comments to everyone. The IETF last call is
two weeks for drafts coming from WGs and four weeks for individual
submission.

If the IESG approves the draft to become an Internet Standard, they ask
the RFC Editor to publish it as a Proposed Standard. After it has been a
Proposed Standard for at least six months, the RFC's author (or the
appropriate WG chair) can ask for it to become a Draft Standard. Before
that happens, however, someone needs to convince the appropriate Area
Director that there are at least two independent interoperable
implementations of each part of the standard. This is a good test for
the usefulness of the standard as a whole, as well as an excellent way
to check if the standard was really readable.

A few things typically happen at this point. First, it is common to find
that some of the specifications in the standard need to be reworded
because one implementor thought they meant one thing while another
implementor thought they meant something else. Another common occurrence
is that none of the implementations actually tried to implement a few of
the features of the standard; these features get removed not just
because no one tested them, but also because they weren't needed.

You should not be surprised if a particular standard does not progress
from Proposed to Draft. In fact, most of the standards in common use are
Proposed Standards and never move forwards. This may be due to no one
taking the time to try to get them to Draft, or some of the normative
references in the standard are still at Proposed Standard, or it may be
that there more important things to do.

A few years after something has been a Draft Standard, it can become a
Internet Standard, also known as "full standard". This doesn't happen
often, and is usually reserved for protocols that are absolutely
required for the Internet to function. The IESG does a great deal of
scrutiny before making a Draft Standard an Internet Standard.

9.3.1 Using MUST and SHOULD and MAY

Writing specifications that get implemented the way you want is a bit of
an art. You can keep the specification very short, with just a list of
requirements, but that tends to cause implementors to take too much
leeway. If you instead make the specification very wordy with lots of
suggestions, implementors tend to miss the requirements (and often
disagree with your suggestions anyway). An optimal specification is
somewhere in between.

One method to make it more likely that developers will create
interoperable implementations of standards is to make sure it is clear
what is being mandated in a specification. Early RFCs used a variety of
language to say how to do things, and this caused implementors to not
know which parts were suggestions and which parts were requirements.
Standards writers in the IETF generally agreed to limit their wording to
a few specific words with a few specific meanings.

RFC 1123, "Requirements for Internet Hosts -- Application and Support",
written way back in 1989, had a short list of words that had appeared to
be useful, namely "must", "should", and "may". These definitions were
updated and further refined in BCP 14, "Key words for use in RFCs to
Indicate Requirement Levels", which is widely referenced in current
Internet standards. BCP 14 also specifically defines "must not" and
"should not", and lists a few synonyms for the words defined.

In a standard, in order to make it clear that you are using the
definitions from BCP 14, you should do two things. First, you should
refer to BCP 14 (although most people refer to it as RFC 2119, because
that is what BCP 14 tells you to do), so that the reader knows how you
are defining your words. Second, you should point out which instances of
the words you are using come from BCP 14; the accepted practice for this
is to capitalize the words. That is why you see "MUST" and "SHOULD"
capitalized in IETF standards.

BCP 14 is a short document, and should be read by everyone who is
reading or writing IETF standards. Although the definitions of "must"
and "must not" are fairly clear, the definitions of "should" and "should
not" cause a great deal of discussion in many WGs. When reviewing an
Internet Draft, the question is often raised, "should that sentence have
a MUST or a SHOULD in it?" This is, indeed, a very good question,
because specifications shouldn't have gratuitous MUSTs, but also should
not have SHOULDs where a MUST is needed for interoperability. This goes
to the crux of the question of over-specifying and under-specifying
requirements in standards.

9.3.2 Normative References in Standards

One aspect of writing IETF standards that trips up many novices (and
quite a few long-time IETF folk) is the rule about how to make
"normative references" to non-IETF documents or to other RFCs in a
standard. A normative reference is a reference to a document that must
be followed in order to implement the standard; a non-normative
reference is one that is helpful to an implementor but is not needed. As
described above, a "MUST" specification would certainly be normative, so
any reference needed to implement the "MUST" would be normative. A
"SHOULD" or "MAY" specification is not necessarily normative, but it
might be normative based on what is being required; there is definitely
room for debate here.

An IETF standard may make a normative reference to any other
standards-track RFC that is at the same standards level or higher, or to
any "open standard" that has been developed outside the IETF. The "same
level or higher" rule means that before a standard can move from
Proposed to Draft, all of the RFCs for which there is a normative
reference must also be at Draft or Internet Standard. This rule gives
implementors assurance that everything in a Draft Standard or Internet
Standard is quite stable, even the things referenced outside the
standard. This can also delay the publication of the Draft or Internet
Standard by many months (sometimes even years) while the other documents
catch up.

There is no hard and fast rule about what is an "open standard", but it
generally means a stable standard that anyone can get a copy of
(although they might have to pay for it) and that was made by a
generally-recognized standards group. If the external standard changes,
you have to reference the particular instantiation of that standard in
your specification, such as with a designation of the date of the
standard. Some external standards bodies do not make old standards
available, which is a problem for IETF standards that need to be used in
the future. When in doubt, a draft author should ask the WG chair or
appropriate Area Director if a particular external standard can be used
in an IETF standard.

9.3.3 IANA Considerations

More and more IETF standards require the registration of some protocol
parameters, such as named options in the protocol. The main registry for
all IETF standards has been IANA. Because of the large and diverse kinds
of registries that standards require, IANA needs to have specific
information about how to register the parameters, what not to register,
who (if anyone) will decide what is to be registered, and so on.

Anyone writing an Internet standard that may need an IANA registry needs
to read BCP 26, "Guidelines for Writing an IANA Considerations Section
in RFCs", which describes how RFC authors should properly ask for IANA
to start or take over a registry. IANA also maintains registries that
were started long before BCP 26 was produced.

9.3.4 Patents in IETF Standards

The problems of intellectual property have cropped up more in the past
few years, particularly with respect to patents. The goal of the IETF is
to have its standards widely used and validated in the marketplace. If
creating a product that uses a standard requires getting a license for a
patent, people are less likely to implement the standard. Thus, the
general rule has been "use good non-patented technology where possible."

Of course, this isn't always possible. Sometimes patents appear after a
standard has been established. Sometimes there is a patent on something
that is so valuable that there isn't a non-patented equivalent.
Sometimes, the patent holder is generous and promises to give all
implementors of a standard a royalty-free license to the patent, thereby
making it almost as easy to implement as it would have been if no patent
existed.

The IETF's methods for dealing with patents in standards are a subject
of much debate. You can read about the official rules in BCP 9, but you
should assume that the application of those rules is flexible and
depends on the type of patent, the patent holder, and the availability
of alternate technologies that are not encumbered by patents.

Patent holders who freely allow their patents to be used by people
implementing IETF standards often get a great deal of good will from the
folks in the IETF. Such generosity is more common than you might think.
For example, RFC 1822 is a license from IBM for one of its security
patents, and the security community has responded very favorably to IBM
for this (whereas a number of other companies have made themselves
pariahs for their intractability on their security patents).

9.4 Informational and Experimental RFCs

As stated earlier, not all RFCs are standards. In fact, plenty of
important RFCs are not on standards track at all. Currently, there are
two designations for RFCs that are not meant to be standards:
Informational and Experimental. (There is actually a third, Historical,
but that is reserved for things that were on standards track and have
been removed due to lack of current use or that more recent thinking
indicates the technology is actually harmful to the Internet.)

The role of Informational RFCs is often debated in the IETF. Many people
like having them, particularly for specifications that were created
outside the IETF but are referenced by IETF documents. They are also
useful for specifications that are the precursors for work being done by
IETF Working Groups. On the other hand, some people refer to
Informational RFCs as "standards" even though the RFCs are not
standards, usually to fool the gullible public about something that the
person is selling or supporting. When this happens, the debate about
Informational RFCs is renewed.

Experimental RFCs are for specifications that may be interesting, but
for which it is unclear if there will be much interest in implementing
them. That is, a specification might solve a problem, but if it is not
clear many people think that the problem is important, or think that
they will bother fixing the problem with the specification, the
specification might be labeled an Experimental RFC. If, later, the
specification becomes popular, it can be re-issued as a standards-track
RFC. Experimental RFCs are also used to get people to experiment with a
technology that looks like it might be standards track material, but for
which there are still unanswered questions.

. IETF's Relationship to Other Standards Groups

As much as many IETF participants would like to think otherwise, the
IETF does not exist in a standards vacuum. There are many (perhaps too
many) other standards organizations whose decisions affect the Internet.
There are also a fair number of standards bodies who ignored the
Internet for a long time and now want to get a piece of the action.

In general, the IETF tries to have cordial relationships with other
significant standards bodies. This isn't always easy, since many other
bodies have very different structures than the IETF, and the IETF is
mostly run by volunteers who would probably prefer to write standards
rather than meet with representatives from other bodies. Even so, some
other standards bodies make a great effort to interact well with the
IETF despite the obvious cultural differences.

At the time of this writing, the IESG has some liaisons with large
standards bodies, including the ITU (International Telecommunication
Union), the W3C, the Unicode Consortium, the ATM Forum, and ISO-IEC/JTC1
(The Joint Technical Committee of the International Organization for
Standardization and International Electrotechnical Commission). The IESG
list of liaisons shows that there are many different liaisons to
ISO-IEC/JTC1 subcommittees.

. Press Coverage of the IETF

Given that the IETF is one of the best-known bodies that is helping move
the Internet forwards, it is natural for the computer press (and even
the trade press) to want to cover the actions of the IETF. Such
publicity is a good thing for the IETF if it is accurate. As you can
imagine, it is easy for the press to get stories about the IETF wrong,
and they seem to do so regularly.

Major press errors fall into two categories: saying that the IETF is
considering something when in fact there is just an Internet Draft in a
Working Group, and saying that the IETF approved something when all that
happened was that an Informational RFC was published. In both cases, the
press is not fully to blame for the problem, since they are usually
alerted to the story by a company trying to get publicity for a protocol
that they developed or at least support. Of course, a bit of research by
the reporter would probably get them in contact with someone who can
straighten them out, such as a WG chair or an Area Director. The
official press contact for the IETF is Steve Coya, who leads the IETF
Secretariat.

Reporters who want to find out about "what the IETF is doing" on a
particular topic would be well-advised to talk to more than one person
who is active on that topic in the IETF, and should probably try to talk
to the WG chair in any case. It is impossible to determine what will
happen with a draft by looking at the draft or talking to the draft's
author. Fortunately, all WGs have archives that a reporter can look
through for recent indications about what the progress of a draft is;
unfortunately, few reporters have the time or inclination to do this
kind of research. Because the IETF doesn't have a press liaison, a
magazine or newspaper that runs a story with errors won't hear directly
from the IETF and therefore often won't know what they did wrong, so
they might easily do it again later.

. How to Contribute to the IETF

Read -- Review the Internet Drafts in your area of expertise, and
comment on them in the Working Groups. Participate in the discussion in
a friendly, helpful fashion, with the goal being the best Internet
standards possible. Listen much more than you speak.

Implement -- Write programs that use the current Internet standards. The
standards aren't worth much unless they are available to Internet users.
Implement even the "minor" standards, since they will become less minor
if they appear in more software. Report any problems you find with the
standards to the appropriate Working Group so that the standard can be
clarified in later revisions. One of the oft-quoted tenets of the IETF
is "running code wins", so you can help support the standards you want
to see become more wide-spread by creating more running code.

Write -- Edit or co-author Internet Drafts in your area of expertise. Do
this for the benefit of the Internet community, not so you have your
name (or, even worse, your company's name) on a document. Draft authors
are subject to all kinds of technical (and sometimes personal)
criticism; receive it with equanimity and use it to improve your draft
in order to produce the best and most interoperable standard.

Open -- Eschew proprietary standards. If you are an implementor, exhibit
a strong preference to IETF standards. If the IETF standards aren't as
good as the proprietary standards, work to make the IETF standards
better. If you are a purchaser, avoid products that use proprietary
standards that compete with the open standards of the IETF, and tell the
companies you buy from that you are doing so.

Free -- If your company controls a patent that is used in an IETF
standards, convince them to make the patent available at no cost to
everyone who is implementing the standard. In the past few years,
patents have caused numerous serious problems for Internet standards
because they prevent some companies from being able to freely implement
the standards. Fortunately, many companies have generously offered
unlimited licenses for particular patents in order to help the IETF
standards flourish. These companies are usually rewarded with positive
publicity for the fact that they are not as greedy or short-sighted as
other patent-holders.

Join -- Become a member of ISOC. More importantly, urge any company that
has benefited from the Internet to become a corporate member of ISOC,
since this has the greatest financial benefit for the group. It will, of
course, also benefit the Internet as a whole.

. References

[[TBD]]]

A. Area Abbreviations

APP  Applications
GEN  General Interest
INT  Internet
OPS  Operations & Management
RTG  Routing
SEC  Security
TSV  Transport
USV  User Services

B. Acronyms used in the document

[[TBD]]

C. Editor Contact

Susan Harris
Merit Network, Inc.
 Plymouth Road, Suite C
Ann Arbor, MI  48105
srh@merit.edu