Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/0tao.txt

Text File | 1997-06-24 | 28KB | 559 lines

The Tao of IETF -- A Guide for New Attendees of the Internet
Engineering Task Force

[The following is excerpted from RFC 1718, "The Tao of the IETF",
authored by the IETF Secretariat and Gary Malkin of Bay Networks.]

Abstract

Over the last several years, the attendance at Internet Engineering
Task Force (IETF) plenary meetings has grown phenomenally.
Approximately one third of the attendees are new to the IETF at each
meeting, and many of those go on to become regular attendees. When the
meetings were smaller, it was relatively easy for a newcomer to get
into the swing of things. Today, however, a newcomer meets many more
new people, some previously known only as the authors of documents or
thought provoking e-mail messages.

The purpose of this For Your Information (FYI) RFC 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 more productive for everyone. This
FYI will also provide the mundane bits of information which everyone
who attends an IETF meeting should know.

Table of Contents

- Section 1 - The "Fun" Stuff

- What is the IETF?  - Humble Beginnings - The Hierarchy - IETF Mailing
Lists - Newcomers' Orientation - Dress Code - Seeing Spots Before Your
Eyes - Terminal Room - Social Event - Agenda - Other General Things

- Section 2 - The "You've got to know it" Stuff

- Mailing Lists and Archives - InterNIC Archives - Be Prepared - RFCs
and Internet-Drafts - Useful Documents and Files

- Section 3 - The "Reference" Stuff

- Tao - IETF Area Abbreviations - Acronyms - Acknowledgements


What is the IETF?

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.

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.

The IETF met in Amsterdam, The Netherlands, in July, 1993. This was the
the first IETF meeting held in Europe, and the US/non-US attendee split
was nearly 50/50.

The Hierarchy

To completely understand the structure of the IETF, it is useful to
understand the overall structure in which the IETF resides. There are
four groups in the structure: the ISOC and its Board of Trustees, the
IAB, the IESG and the IETF itself.

The Internet Society is a professional society that is concerned with
the growth and evolution of the worldwide Internet, with the way in
which the Internet is and can be used, and with the social, political,
and technical issues which arise as a result. The ISOC Trustees are
responsible for approving appointments to the IAB from among the
nominees submitted by the IETF nominating committee.

The IAB is a technical advisory group of the ISOC. It is chartered to
provide oversight of the architecture of the Internet and its
protocols, and to serve, in the context of the Internet standards
process, as a body to which the decisions of the IESG may be appealed.
The IAB is responsible for approving appointments to the IESG from
among the nominees submitted by the IETF nominations committee.

The IESG is responsible for technical management of IETF activities and
the Internet standards process. As part of the ISOC, it administers the
process according to the rules and procedures which have been ratified
by the ISOC Trustees. The IESG is directly responsible for the actions
associated with entry into and movement along the Internet "standards
track," including final approval of specifications as Internet
Standards.

The IETF is divided into eight functional areas. They are:
Applications, Internet, IP: Next Generation, Network Management,
Operational Requirements, Routing, Security, Transport and User
Services. Each area has one or two area directors. The area directors,
along with the IETF/IESG Chair, form the IESG. Fred Baker is the
current IETF/IESG chair.

Each area has several working groups. A working group is a group of
people who work under a charter to achieve a certain goal. That goal
may be the creation of an Informational document, the creation of a
protocol specification, or the resolution of problems in the Internet.
Most working groups have a finite lifetime. That is, once a working
group has achieved its goal, it disbands. As in the IETF, there is no
official membership for a working group. Unofficially, a working group
member is somebody who is on that working group's mailing list;
however, anyone may attend a working group meeting (see the Be Prepared
section below).

Areas may also have Birds of a Feather (BOF) sessions. They generally
have the same goals as working groups, except that they have no charter
and usually only meet once or twice. BOFs are often held to determine
if there is enough interest to form a working group.

IETF 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. People who would like to "get
technical" may also join the IETF discussion list, "[e-mail]".
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 announcement list, send a request to:

[e-mail]

To join the IETF discussion list, send a request to:

[e-mail]

To join both of the lists, simply send a single message, to either
"-request" address, and indicate that you'd like to join both lists.

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.

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.

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!

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

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.

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.

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
Marshall 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.

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
handed out at the meeting. Changes occuring during the meeting are
posted on the bulletin board near the IETF 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.

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 typically 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.

Mailing Lists and Archives

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.

All 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.

InterNIC Archives

There is a tremendous amount of material available for those who follow
the work of the IETF. To make it easier to know what to read to prepare
for a meeting, the InterNIC has established a document archive.
Beginning about one month prior to an IETF meeting, working group/BOF
chairs and area directors put documents relevant to the discussions to
be held into the archives. Those people who plan to attend a working
group/BOF session should check the archives for documents which need to
be read. The documents are left in the archives for about two months
after the end of the IETF meeting.

On the host "ds.internic.net", documents are stored in the directory
"/pub/current-ietf-docs" under subdirectories named for each area and
then for each working group. For example, a document for the NISI
Working Group, which is in the User Services Area, would be stored as
"current-ietf-docs/usv/nisi/nisi-doc1.txt". Each area will also have a
subdirectory called "bof", where documents to be discussed in BOF
sessions will be placed. A directory called "plenary" will also be
created under "/pub/current-ietf-docs" to put documents or viewgraphs
related to a plenary session. Any filename conflicts will be resolved
by the archive administrator working with the submitter of the document
via e- mail.

It is important to note that the service is provided by the InterNIC
and that the documents are submitted by the people who work on them.
The IETF Secretariat does not manage or monitor the archive service.

Be Prepared

This topic cannot be stressed enough. As the IETF grows, it becomes
more and more important for attendees to arrive prepared for the
working group meetings they plan to attend. This doesn't apply only to
newcomers--everybody should come prepared.

Being prepared means having read the documents which the working group
or BOF chair has distributed. It means having followed the discussions
on the working group's mailing list or having reviewed the archives.
For the working group/BOF chairs, it means getting all of the documents
out early (i.e., several weeks) to give everybody time to read them and
announcing an agenda and sticking to it.

At the chair's discretion, some time may be devoted to bringing new
working group attendees up to speed. In fact, long lived working groups
have occasionally held entire sessions which were introductory in
nature. As a rule, however, a working group is not the place to go for
training. Observers are always welcome, but they must realize that the
work effort cannot be delayed for education. Anyone wishing to attend a
working group for the first time might seek out the chair prior to the
meeting and ask for some introduction.

Another thing for everybody to consider is that working groups go
through phases. In the initial phase (say, the first two meetings), all
ideas are welcome. The idea is to gather all the possible solutions
together for consideration. In the development phase, a solution is
chosen and developed. Trying to reopen issues which were decided more
than a couple of meetings back is considered bad form. The final phase
(the last two meetings) is where the "spit and polish" are applied to
the architected solution. This is not the time to suggest architectural
changes or open design issues already resolved. It's a bad idea to wait
until the last minute to speak out if a problem is discovered. This is
especially true for people whose excuse is that they hadn't read the
documents until the day before a comments period ended.

Time at the IETF meetings is a precious thing. Working groups are
encouraged to meet between IETF meetings, either in person or by video
or telephone conference. Doing as much work as possible over the
mailing lists would also reduce the amount of work which must be done
at the meeting.

RFCs and Internet-Drafts

Originally, RFCs were just what the name implies: requests for
comments. The early RFCs were messages between the ARPANET architects
about how to resolve certain problems.  Over the years, RFCs became
more formal. It reached the point that they were being cited as
standards, even when they weren't.

To help clear up some confusion, there are now two special sub-series
within the RFCs:  FYIs and STDs. The For Your Information RFC sub-
series was created to document overviews and topics which are
introductory. Frequently, FYIs are created by groups within the IETF
User Services Area. The STD RFC sub-series was created to identify
those RFCs which do in fact specify Internet standards.

Every RFC, including FYIs and STDs, have an RFC number by which they
are indexed and by which they can be retrieved. FYIs and STDs have FYI
numbers and STD numbers, respectively, in addition to RFC numbers. This
makes it easier for a new Internet user, for example, to find all of
the helpful, informational documents by looking for the FYIs amongst
all the RFCs. If an FYI or STD is revised, its RFC number will change,
but its FYI or STD number will remain constant for ease of reference.

There is also an RTR subseries of RFCs for Reseaux Associes pour la
Recherche Europeenne (RARE) Technical Reports. These are technical
reports developed in the RARE community that are published as RFCs to
provide easy access to the general Internet community.

Internet-Drafts are working documents of the IETF. Any group or
individual may submit a document for distribution as an Internet-
Draft. These documents are valid for six months, and may be updated,
replaced or obsoleted at any time. Guidelines require that an
expiration date appear on every page of an Internet-Draft. It is not
appropriate to use Internet-Drafts as reference material or to cite
them, other than as "working drafts" or "works in progress."



- Request for Comments on Request for Comments [RFC 1111] - F.Y.I. on
F.Y.I: Introduction to the F.Y.I notes [FYI1] - Introduction to the STD
Notes [RFC 1311] - Guidelines to Authors of Internet-Drafts [GAID] -
The Internet Activities Board [RFC 1160] - The Internet Standards
Process [RFC 2026] - Internet Official Protocol Standards [STD1]

Useful Documents and Files

Detailed descriptions of current Working Groups, their charters,
Internet-Drafts and RFCs, meeting registration, past meeting
proceedings, current IESG activities/actions, and other information is
available at the IETF Web site, www.ietf.org.

Tao

Pronounced "dow", Tao means "the way." It is the basic principle behind
the teachings of Lao-tse, a Chinese master. Its familiar symbol is the
black and white Yin-Yang circle.

IETF Area Abbreviations

- APP - Applications - INT - Internet Services - IPNG - IP: Next
Generation - MGT - Network Management - OPS - Operational Requirements
- RTG - Routing - SEC - Security - TSV - Transport - USV - User
Services

Acronyms

- ANSI - American National Standards Institute - ARPA - Advanced
Research Projects Agency - ARPANET - Advanced Research Projects Agency
Network - AS - Autonomous System - ATM - Asynchronous Transfer Mode -
BGP - Border Gateway Protocol - BOF - Birds Of a Feather - BSD -
Berkeley Software Distribution - BTW - By The Way - CCIRN -
Coordinating Committee for Intercontinental Research Networks - CCITT -
International Telegraph and Telephone Consultative Committee - CIDR -
Classless Inter-Domain Routing - CIX - Commercial Information Exchange
- CNI - Coalition for Networked Information - CREN - The Corporation
for Research and Educational Networking - DARPA - US Defense Advanced
Research Projects Agency (now ARPA) - DDN - US Defense Data Network -
DISA - US Defense Information Systems Agency - EGP - Exterior Gateway
Protocol - FAQ - Frequently Asked Question - FARNET - Federation of
American Research NETworks - FIX - US Federal Information Exchange -
FNC - US Federal Networking Council - FQDN- Fully Qualified Domain Name
- FYI - For Your Information (RFC) - GOSIP- US Government OSI Profile -
IAB - Internet Architecture Board - IANA - Internet Assigned Numbers
Authority - I-D - Internet-Draft - IEN - Internet Experiment Note -
IESG - Internet Engineering Steering Group - IETF - Internet
Engineering Task Force - IGP - Interior Gateway Protocol - IMHO - In My
Humble Opinion - IMR - Internet Monthly Report - InterNIC - Internet
Network Information Center - IPng - IP: Next Generation - IR - Internet
Registry - IRSG - Internet Research Steering Group - IRTF - Internet
Research Task Force - ISO - International Organization for
Standardization - ISOC - Internet Society - ISODE - ISO Development
Environment - ITU - International Telecommunication Union - MIB -
Management Information Base - MIME - Multipurpose Internet Mail
Extensions - NIC - Network Information Center - NIS - Network
Information Services - NIST - National Institute of Standards and
Technology - NOC - Network Operations Center - NREN - National Research
and Education Network - NSF - National Science Foundation - OSI - Open
Systems Interconnection - PEM - Privacy Enhanced Mail - PTT - Postal,
Telegraph and Telephone - RARE - Reseaux Associes pour la Recherche
Europeenne - RFC - Request For Comments - RIPE - Reseaux IP Europeenne
- SIG - Special Interest Group - STD - Standard (RFC) - TLA - Three
Letter Acronym - TTFN - Ta-Ta For Now - UTC - Universal Time
Coordinated - WG - Working Group - WRT - With Respect To - WYSIWYG -
What You See is What You Get

Acknowledgments

The IETF Secretariat would like to acknowledge the time and efforts of
Gary Malkin, who prepared the original RFC from which this material has
been excerpted and who coordinated the changes to the first revision.
Without his help, this document might still be "in progress."

IETF Secretariat - Please send problem reports and comments to
[e-mail].