tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4677


Pages: 50
Top     in Index     Prev     Next
 

The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force

Part 1 of 2, p. 1 to 22
None       Next RFC Part

Obsoleted by:    6722
Obsoletes:    3160


Top       ToC       Page 1 
Network Working Group                                         P. Hoffman
Request for Comments: 4677                                VPN Consortium
FYI: 17                                                        S. Harris
Obsoletes: 3160                                   University of Michigan
Category: Informational                                   September 2006


                 The Tao of IETF: A Novice's Guide to
                  the Internet Engineering Task Force

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the inner workings of IETF meetings and
   Working Groups, discusses organizations related to the IETF, and
   introduces the standards process.  It is not a formal IETF process
   document but instead an informational overview.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
   2. Acknowledgements ................................................5
   3. What Is the IETF? ...............................................5
      3.1. Humble Beginnings ..........................................6
      3.2. The Hierarchy ..............................................7
           3.2.1. ISOC (Internet Society) .............................7
           3.2.2. IESG (Internet Engineering Steering Group) ..........8
           3.2.3. IAB (Internet Architecture Board) ..................10
           3.2.4. IANA (Internet Assigned Numbers Authority) .........11
           3.2.5. RFC Editor .........................................11
           3.2.6. IETF Secretariat ...................................12
      3.3. IETF Mailing Lists ........................................12
   4. IETF Meetings ..................................................13
      4.1. Registration ..............................................14
      4.2. Take the Plunge and Stay All Week! ........................15
      4.3. Newcomer Training .........................................16
      4.4. Dress Code ................................................16
      4.5. Seeing Spots Before Your Eyes .............................16
      4.6. Terminal Room .............................................17
      4.7. Meals and Other Delights ..................................17
      4.8. Social Event ..............................................18
      4.9. Agenda ....................................................18
      4.10. EDU to the Rescue ........................................19
      4.11. Where Do I Fit In? .......................................19
           4.11.1. IS Managers .......................................19
           4.11.2. Network Operators and ISPs ........................19
           4.11.3. Networking Hardware and Software Vendors ..........20
           4.11.4. Academics .........................................20
           4.11.5. Computer Trade Press ..............................20
      4.12. Proceedings ..............................................21
      4.13. Other General Things .....................................21
   5. Working Groups .................................................22
      5.1. Working Group Chairs ......................................23
      5.2. Getting Things Done in a Working Group ....................24
      5.3. Preparing for Working Group Meetings ......................25
      5.4. Working Group Mailing Lists ...............................26
      5.5. Interim Working Group Meetings ............................27
   6. BOFs ...........................................................27
   7. New to the IETF and Coming to a Meeting? STOP HERE!
      (Temporarily) ..................................................28
   8. RFCs and Internet Drafts .......................................29
      8.1. Getting an RFC Published ..................................29
      8.2. Letting Go Gracefully .....................................30
      8.3. Internet Drafts ...........................................31
           8.3.1. Recommended Reading for Writers ....................32
           8.3.2. Filenames and Other Matters ........................33

Top      ToC       Page 3 
      8.4. Standards-Track RFCs ......................................34
           8.4.1. Telling It Like It Is -- Using MUST and SHOULD
                  and MAY ............................................35
           8.4.2. Normative References in Standards ..................36
           8.4.3. IANA Considerations ................................37
           8.4.4. Security Considerations ............................37
           8.4.5. Patents in IETF Standards ..........................37
      8.5. Informational and Experimental RFCs .......................38
   9. How to Contribute to the IETF ..................................39
      9.1. What You Can Do ...........................................39
      9.2. What Your Company Can Do ..................................40
   10. IETF and the Outside World ....................................40
      10.1. IETF and Other Standards Groups ..........................40
      10.2. Press Coverage of the IETF ...............................41
   11. Security Considerations .......................................42
   Appendix A. Related Information ...................................43
      A.1. Why "the Tao"? ............................................43
      A.2. Useful Email Addresses ....................................43
      A.3. Useful Documents and Files ................................44
      A.4. Acronyms and Abbreviations Used in the Tao ................44
   Appendix B. IETF Guiding Principles ...............................45
      B.1. General ...................................................45
      B.2. Management and Leadership .................................45
      B.3. Process ...................................................46
      B.4. Working Groups ............................................46
      B.5. Documents .................................................47
   Informative References ............................................48

Top      ToC       Page 4 
1.  Introduction

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

   This document describes many aspects of the IETF, with the goal of
   explaining to newcomers how the IETF works.  This will give them a
   warm, fuzzy feeling and enable them to make the meeting and the
   Working Group discussions more productive for everyone.

   Of course, it's true that many IETF participants don't go to the
   face-to-face meetings at all.  Instead, they're active on the mailing
   list of various IETF Working Groups.  Since the inner workings of
   Working Groups can be hard for newcomers to understand, this document
   provides the mundane bits of information that newcomers will need in
   order to become active participants.

   The IETF is always in a state of change.  Although the principles in
   this document are expected to remain largely the same over time,
   practical details may well have changed by the time you read it; for
   example, a web-based tool may have replaced an email address for
   requesting some sort of action.

   Many types of IETF documentation are mentioned in the Tao, from BCPs
   to RFCs and FYIs and STDs.  BCPs make recommendations for Best
   Current Practices in the Internet; RFCs are the IETF's main technical
   documentation series, politely known as "Requests for Comments"; FYIs
   provide topical and technical overviews that are introductory or
   appeal to a broad audience; and STDs are RFCs identified as
   "standards".  See Section 8 for more information.

   The acronyms and abbreviations used in this document are usually
   expanded in place and are explained fully in Appendix A.

   This document is intended to obsolete FYI 17, RFC 3160.  See Section
   3.2.5 for information on what it means for one RFC to obsolete
   another.

Top      ToC       Page 5 
2.  Acknowledgements

   The original version of this document, published in 1994, was written
   by Gary Malkin.  His knowledge of the IETF, insights, and unmatched
   writing style set the standard for this later revision, and his
   contributions to the current document are also much appreciated.
   Paul Hoffman wrote significant portions of this revision and provided
   encouragement, expertise, and much-needed guidance.  Other
   contributors include Brian Carpenter, Scott Bradner, Michael Patton,
   Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault,
   the IETF Secretariat, members of the User Services Working Group, and
   members of the PESCI design team.

3.  What Is the IETF?

   The Internet Engineering Task Force is a loosely self-organized group
   of people who contribute to the engineering and evolution of Internet
   technologies.  It is the principal body engaged in the development of
   new Internet standard specifications.  The IETF is unusual in that it
   exists as a collection of happenings, but is not a corporation and
   has no board of directors, no members, and no dues; see [BCP95], "A
   Mission Statement for the IETF", for more detail.

   Its mission includes the following:

   o  Identifying, and proposing solutions to, pressing operational and
      technical problems in the Internet

   o  Specifying the development or usage of protocols and the near-term
      architecture to solve such technical problems for the Internet

   o  Making recommendations to the Internet Engineering Steering Group
      (IESG) regarding the standardization of protocols and protocol
      usage in the Internet

   o  Facilitating technology transfer from the Internet Research Task
      Force (IRTF) to the wider Internet community

   o  Providing a forum for the exchange of information within the
      Internet community between vendors, users, researchers, agency
      contractors, and network managers

   The IETF meeting is not a conference, although there are technical
   presentations.  The IETF is not a traditional standards organization,
   although many specifications are produced that become standards.  The
   IETF is made up of volunteers, many of whom meet three times a year
   to fulfill the IETF mission.

Top      ToC       Page 6 
   There is no membership in the IETF.  Anyone may register for and
   attend any meeting.  The closest thing there is to being an IETF
   member is being on the IETF or Working Group mailing lists (see
   Section 3.3).  This is where the best information about current IETF
   activities and focus can be found.

   Of course, no organization can be as successful as the IETF is
   without having some sort of structure.  In the IETF's case, that
   structure is provided by other organizations, as described in
   [BCP11], "The Organizations Involved in the IETF Standards Process".
   If you participate in the IETF and read only one BCP, this is the one
   you should read.

   In many ways, the IETF runs on the beliefs of its members.  One of
   the "founding beliefs" is embodied in an early quote about the IETF
   from David Clark: "We reject kings, presidents and voting.  We
   believe in rough consensus and running code".  Another early quote
   that has become a commonly-held belief in the IETF comes from Jon
   Postel: "Be conservative in what you send and liberal in what you
   accept".

   The IETF is really about its members.  Because of the unrestrictive
   membership policies, IETF members come from all over the world and
   from many different parts of the Internet industry.  See Section 4.11
   for information about the ways that many people fit into the IETF.

   One more thing that is important for newcomers: the IETF in no way
   "runs the Internet", despite what some people mistakenly might say.
   The IETF makes standards that are often adopted by Internet users,
   but it does not control, or even patrol, the Internet.  If your
   interest in the IETF is because you want to be part of the overseers,
   you may be badly disappointed by the IETF.

3.1.  Humble Beginnings

   The first IETF meeting was held in January 1986 at Linkabit in San
   Diego, with 21 attendees.  The 4th IETF, held at SRI in Menlo Park in
   October 1986, was the first that non-government vendors attended.
   The concept of Working Groups was introduced at the 5th IETF meeting
   at the NASA Ames Research Center in California in February 1987.  The
   7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the
   first meeting with more than 100 attendees.

Top      ToC       Page 7 
   The 14th IETF meeting was held at Stanford University in July 1989.
   It marked a major change in the structure of the IETF universe.  The
   IAB (then Internet Activities Board, now Internet Architecture
   Board), which until that time oversaw many "task forces", changed its
   structure to leave only two: the IETF and the IRTF.  The IRTF is
   tasked to consider long-term research problems in the Internet.  The
   IETF also changed at that time.

   After the Internet Society (ISOC) was formed in January 1992, the IAB
   proposed to ISOC that the IAB's activities should take place under
   the auspices of the Internet Society.  During INET92 in Kobe, Japan,
   the ISOC Trustees approved a new charter for the IAB to reflect the
   proposed relationship.

   The IETF met in Amsterdam, The Netherlands, in July 1993.  This was
   the first IETF meeting held in Europe, and the US/non-US attendee
   split was nearly 50/50.  About one in three IETF meetings are now
   held in Europe or Asia, and the number of non-US attendees continues
   to be high -- about 50%, even at meetings held in the United States.

3.2.  The Hierarchy

3.2.1.  ISOC (Internet Society)

   The Internet Society is an international, non-profit, membership
   organization that fosters the expansion of the Internet.  One of the
   ways that ISOC does this is through financial and legal support of
   the other "I" groups described here, particularly the IETF.  ISOC
   provides insurance coverage for many of the people in the IETF
   process and acts as a public relations channel for the times that one
   of the "I" groups wants to say something to the press.  The ISOC is
   one of the major unsung (and under-supported) heroes of the Internet.

   Starting in spring 2005, the ISOC also became home base for the
   IETF's directly employed administrative staff.  This is described in
   more detail in [BCP101], "Structure of the IETF Administrative
   Support Activity (IASA)".  The staff initially includes only an
   Administrative Director (IAD) who works full-time overseeing IETF
   meeting planning, operational aspects of support services (the
   secretariat, IANA (the Internet Assigned Numbers Authority), and the
   RFC Editor, which are described later in this section), and the
   budget.  He or she (currently it's a he) leads the IETF
   Administrative Support Activity (IASA), which takes care of tasks
   such as collecting meeting fees and paying invoices, and also
   supports the tools for the work of IETF working groups, the IESG, the
   IAB, and the IRTF (more about these later in this section).

Top      ToC       Page 8 
   As well as staff, the IASA comprises volunteers and ex officio
   members from the ISOC and IETF leadership.  The IASA and the IAD are
   directed by the IETF Administrative Oversight Committee (IAOC), which
   is selected by the IETF community.  Here's how all this looks:

                          Internet Society
                                 |
                                IAOC
                                 |
                                IASA
                                 |
                                IAD

   Neither the IAD nor the IAOC have any influence over IETF standards
   development, which we turn to now.

3.2.2.  IESG (Internet Engineering Steering Group)

   The IESG is responsible for technical management of IETF activities
   and the Internet standards process.  It administers the process
   according to the rules and procedures that have been ratified by the
   ISOC Trustees.  However, the IESG doesn't do much direct leadership,
   such as the kind you will find in many other standards organizations.
   As its name suggests, its role is to set directions rather than to
   give orders.  The IESG ratifies or corrects the output from the
   IETF's Working Groups (WGs), gets WGs started and finished, and makes
   sure that non-WG drafts that are about to become RFCs are correct.

   The IESG consists of the Area Directors (ADs), who are selected by
   the Nominations Committee (which is usually called "the NomCom") and
   are appointed for two years.  The process for choosing the members of
   the IESG is detailed in [BCP10], "IAB and IESG Selection,
   Confirmation, and Recall Process: Operation of the Nominating and
   Recall Committees".

   The current areas and abbreviations are shown below.

   Area                    Description
   -----------------------------------------------------------------
   Applications (APP)      Protocols seen by user programs, such as
                           email and the web

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

   Internet (INT)          Different ways of moving IP packets and
                           DNS information

Top      ToC       Page 9 
   Operations and          Operational aspects, network monitoring,
   Management (OPS)        and configuration

   Real-time               Delay-sensitive interpersonal
   Applications and        communications
   Infrastructure (RAI)

   Routing (RTG)           Getting packets to their destinations

   Security (SEC)          Authentication and privacy

   Transport (TSV)         Special services for special packets

   Because the IESG has a great deal of influence on whether Internet
   Drafts become RFCs, many people look at the ADs as somewhat godlike
   creatures.  IETF participants sometimes reverently ask Area Directors
   for their opinion on a particular subject.  However, most ADs are
   nearly indistinguishable from mere mortals and rarely speak from
   mountaintops.  In fact, when asked for specific technical comments,
   the ADs may often defer to members at large whom they feel have more
   knowledge than they do in that area.

   The ADs for a particular area are expected to know more about the
   combined work of the WGs in that area than anyone else.  On the other
   hand, the entire IESG reviews each Internet Draft that is proposed to
   become an RFC.  Any AD may record a "DISCUSS" ballot position against
   a draft if he or she has serious concerns.  If these concerns cannot
   be resolved by discussion, an override procedure is defined such that
   at least two IESG members must express concerns before a draft can be
   blocked from moving forward.  These procedures help ensure that an
   AD's "pet project" doesn't make it onto the standards track if it
   will have a negative effect on the rest of the IETF protocols and
   that an AD's "pet peeve" cannot indefinitely block something.

   This is not to say that the IESG never wields power.  When the IESG
   sees a Working Group veering from its charter, or when a WG asks the
   IESG to make the WG's badly designed protocol a standard, the IESG
   will act.  In fact, because of its high workload, the IESG usually
   moves in a reactive fashion.  It eventually approves most WG requests
   for Internet Drafts to become RFCs, and usually only steps in when
   something has gone very wrong.  Another way to think about this is
   that the ADs are selected to think, not to just run the process.  The
   quality of the IETF standards comes both from the review they get in
   the Working Groups and the scrutiny that the WG review gets from the
   ADs.

Top      ToC       Page 10 
   The IETF is run by rough consensus, and it is the IESG that judges
   whether a WG has come up with a result that has community consensus.
   (See Section 5.2 for more information on WG consensus.)  Because of
   this, one of the main reasons that the IESG might block something
   that was produced in a WG is that the result did not really gain
   consensus in the IETF as a whole, that is, among all of the Working
   Groups in all areas.  For instance, the result of one WG might clash
   with a technology developed in a different Working Group.  An
   important job of the IESG is to watch over the output of all the WGs
   to help prevent IETF protocols that are at odds with each other.
   This is why ADs are supposed to review the drafts coming out of areas
   other than their own.

3.2.3.  IAB (Internet Architecture Board)

   The IAB is responsible for keeping an eye on the "big picture" of the
   Internet, and it focuses on long-range planning and coordination
   among the various areas of IETF activity.  The IAB stays informed
   about important long-term issues in the Internet, and it brings these
   topics to the attention of people it thinks should know about them.
   The IAB web site is at http://www.iab.org/.

   IAB members pay special attention to emerging activities in the IETF.
   When a new IETF Working Group is proposed, the IAB reviews its
   charter for architectural consistency and integrity.  Even before the
   group is chartered, the IAB members are more than willing to discuss
   new ideas with the people proposing them.

   The IAB also sponsors and organizes the Internet Research Task Force
   and convenes invitational workshops that provide in-depth reviews of
   specific Internet architectural issues.  Typically, the workshop
   reports make recommendations to the IETF community and to the IESG.

   The IAB also:

   o  Approves NomCom's IESG nominations

   o  Acts as the appeals board for appeals against IESG actions

   o  Appoints and oversees the RFC Editor

   o  Approves the appointment of the IANA

   o  Acts as an advisory body to ISOC

   o  Oversees IETF liaisons with other standards bodies

Top      ToC       Page 11 
   Like the IESG, the IAB members are selected for multi-year positions
   by the NomCom and are approved by the ISOC Board of Trustees.

3.2.4.  IANA (Internet Assigned Numbers Authority)

   The core registrar for the IETF's activities is the IANA.  Many
   Internet protocols require that someone keep track of protocol items
   that were added after the protocol came out.  Typical examples of the
   kinds of registries needed are for TCP port numbers and MIME types.
   The IAB has designated the IANA organization to perform these tasks,
   and the IANA's activities are financially supported by ICANN, the
   Internet Corporation for Assigned Names and Numbers.

   Ten years ago, no one would have expected to see the IANA mentioned
   on the front page of a newspaper.  IANA's role had always been very
   low key.  The fact that IANA was also the keeper of the root of the
   domain name system forced it to become a much more public entity, one
   that was badly maligned by a variety of people who never looked at
   what its role was.  Nowadays, the IETF is generally no longer
   involved in the IANA's domain name and IP address assignment
   functions, which are overseen by ICANN.

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

3.2.5.  RFC Editor

   The RFC Editor edits, formats, and publishes Internet Drafts as RFCs,
   working in conjunction with the IESG.  An important secondary role is
   to provide one definitive repository for all RFCs (see
   http://www.rfc-editor.org).  Once an RFC is published, it is never
   revised.  If the standard it describes changes, the standard will be
   re-published in another RFC that "obsoletes" the first.

   One of the most popular misconceptions in the IETF community is that
   the role of the RFC Editor is performed by IANA.  In fact, the RFC
   Editor is a separate job, although both the RFC Editor and IANA
   involved the same people for many years.  The IAB approves the
   organization that will act as RFC Editor and the RFC Editor's general
   policy.  The RFC Editor is funded by IASA and can be contacted by
   email at mailto:rfc-editor@rfc-editor.org.

Top      ToC       Page 12 
3.2.6.  IETF Secretariat

   There are, in fact, a few people who are paid to maintain the IETF.
   The IETF Secretariat provides day-to-day logistical support, which
   mainly means coordinating face-to-face meetings and running the
   IETF-specific mailing lists (not the WG mailing lists).  The
   Secretariat is also responsible for keeping the official Internet
   Drafts directory up to date and orderly, maintaining the IETF web
   site, and helping the IESG do its work.  It provides various tools
   for use by the community and the IESG.  The IETF Secretariat is under
   contract to IASA, which in turn is financially supported by the fees
   of the face-to-face meetings.

3.3.  IETF Mailing Lists

   Anyone who plans to attend an IETF meeting should join the IETF
   announcement mailing list, mailto:ietf-announce@ietf.org.  This is
   where all of the meeting information, RFC announcements, and IESG
   Protocol Actions and Last Calls are posted.  People who would like to
   "get technical" may also join the IETF general discussion list,
   ietf@ietf.org.  This is where discussions of cosmic significance are
   held (Working Groups have their own mailing lists for discussions
   related to their work).  Another mailing list, mailto:i-d-
   announce@ietf.org, announces each new version of every Internet Draft
   as it is published.

   Subscriptions to these and other IETF-run mailing lists are handled
   by a program called "mailman".  Mailman can be somewhat finicky about
   the format of subscription messages, and sometimes interacts poorly
   with email programs that make all email messages into HTML files.
   Mailman will treat you well, however, if you format your messages
   just the way it likes.

   To join the IETF announcement list, for example, send email to
   mailto:ietf-announce-request@ietf.org.  Enter the word 'subscribe'
   (without the quotes) in the Subject line of the message and in the
   message body.  To join the IETF discussion list, send email to
   <mailto:ietf-request@ietf.org> and enter the word 'subscribe' as
   explained above.  If you decide to withdraw from either list, use the
   word 'unsubscribe'.  Your messages to mailman should have nothing
   other than the commands 'subscribe' or 'unsubscribe' in them.  Both
   lists are archived on the IETF web site,
   http://www.ietf.org/maillist.html.

Top      ToC       Page 13 
   Do not, ever, under any circumstances, for any reason, send a request
   to join a list to the list itself!  The thousands of people on the
   list don't need, or want, to know when a new person joins.
   Similarly, when changing email addresses or leaving a list, send your
   request only to the "-request" address, not to the main list.  This
   means you!!

   The IETF discussion list is unmoderated.  This means that all can
   express their opinions about issues affecting the Internet.  However,
   it is not a place for companies or individuals to solicit or
   advertise, as noted in [BCP45], "IETF Discussion List Charter".  It
   is a good idea to read the whole RFC (it's short!) before posting to
   the IETF discussion list.  Actually, the list does have two
   "sergeants at arms" who keep an eye open for inappropriate postings,
   and there is a process for banning persistent offenders from the
   list, but fortunately this is extremely rare.

   Only the Secretariat and certain IETF office holders can approve
   messages sent to the announcement list, although those messages can
   come from a variety of people.

   Even though the IETF mailing lists "represent" the IETF membership at
   large, it is important to note that attending an IETF meeting does
   not mean you'll be automatically added to either mailing list.

4.  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 "gatherings of the tribes" whose primary
   goal is to reinvigorate the WGs to get their tasks done, and whose
   secondary goal is to promote a fair amount of mixing between the WGs
   and the areas.  The cost of the meetings is paid by the people
   attending and by the corporate host for each meeting (if any),
   although IASA kicks in additional funds for things such as the audio
   broadcast of some Working Group sessions.

   For many people, IETF meetings are a breath of fresh air when
   compared to the standard computer industry conferences.  There is no
   exposition hall, few 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.  The past few meetings have

Top      ToC       Page 14 
   had about 1,300 attendees.  There have been more than 65 IETF
   meetings so far, and a list of upcoming meetings is available on the
   IETF web pages, http://www.ietf.org/meetings/0mtg-sites.txt.

   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 people in a WG meeting apparently reading
   email or perusing the web during presentations they find
   uninteresting.  Remember, however, that they may also be consulting
   the drafts under discussion, looking up relevant material online, or
   following another meeting using instant messaging.

4.1.  Registration

   To attend an IETF meeting, you have to register and you have to pay
   the registration fee.  The meeting site and advance registration are
   announced about two months ahead of the meeting -- earlier if
   possible.  An announcement goes out via email to the IETF-announce
   mailing list, and information is posted on the IETF web site,
   http://www.ietf.org, that same day.

   To pre-register, you must submit your registration on the web.  You
   may pre-register and pre-pay, pre-register and return to the web site
   later to pay with a credit card, pre-register and pay on-site at the
   meeting, or register and pay on-site.  To get a lower registration
   fee, you must pay by the early registration deadline (about one week
   before the meeting).  The registration fee covers all of the week's
   meetings, the Sunday evening reception (cash bar), daily continental
   breakfasts, and afternoon coffee and snack breaks.

   Credit card payments on the web are encrypted and secure, or, if you
   prefer, you can use Pretty Good Privacy (PGP) to send your payment
   information to the Registrar (mailto:ietf-registrar@ietf.org).

   Registration is open throughout the week of the meeting.  However,
   the Secretariat highly recommends that attendees arrive for early
   registration, usually beginning at noon on Sunday and continuing
   throughout the Sunday evening reception.  The reception is a popular
   event where you can get a small bite to eat and socialize with other
   early arrivals.

   Registered attendees (and there aren't any other kind) receive a
   registration packet.  It contains much useful information, including
   a general orientation sheet, the most recent agenda, and a name tag.

Top      ToC       Page 15 
   Attendees who pre-paid will also find their receipt in their packet.
   It's worth noting that neither attendee names and addresses nor IETF
   mailing lists are ever offered for sale.

   In your registration packet is a sheet titled "Note Well".  You
   should indeed read it carefully because it lays out the rules for
   IETF intellectual property rights.

   If you need to leave messages for other attendees, you can do so at
   the cork boards that are often near the registration desk.  These
   cork boards will also have last-minute meeting changes and room
   changes.

   You can also turn in lost-and-found items to the registration desk.
   At the end of the meeting, anything left over from the lost and found
   will usually be turned over to the hotel or brought back to the
   Secretariat's office.

   Incidentally, the IETF registration desk is often a convenient place
   to arrange to meet people.  If someone says "meet me at
   registration", they almost always mean the IETF registration desk,
   not the hotel registration desk.

4.2.  Take the Plunge and Stay All Week!

   IETF meetings last from Monday morning through Friday lunchtime.
   Associated meetings often take place on the preceding or following
   weekends.  It is best to plan to be present the whole week, to
   benefit from cross-fertilization between Working Groups and from
   corridor discussions.  As noted below, the agenda is fluid, and there
   have been many instances of participants missing important sessions
   due to last-minute scheduling changes after their travel plans were
   fixed.  Being present the whole week is the only way to avoid this
   annoyance.

   If you cannot find meetings all week to interest you, you can still
   make the most of the IETF meeting by working between sessions.  Most
   IETF attendees carry laptop computers, and it is common to see many
   of them in the terminal room or in the hallways working during
   meeting sessions.  There is often good wireless Internet coverage in
   many places of the meeting venue (restaurants, coffee shops, and so
   on), so catching up on email when not in meetings is a fairly common
   task for IETFers.

Top      ToC       Page 16 
4.3.  Newcomer Training

   Newcomers are encouraged to attend the Newcomer Training, which is
   especially designed for first-time attendees.  The orientation is
   organized and conducted by the IETF EDU team and is intended to
   provide useful introductory information.  The session covers what's
   in the attendee packets, what all the dots on name tags mean, the
   structure of the IETF, and many other essential and enlightening
   topics for new IETFers.

   Immediately following the Newcomers' Training is the IETF Standards
   Process Orientation.  This session demystifies much of the standards
   process by explaining what stages a document has to pass through on
   its way to becoming a standard, and what has to be done to advance to
   the next stage.

   There is usually ample time at the end for questions.  The
   Secretariat provides hard copies of the slides of the "IETF Structure
   and Internet Standards Process" presentation -- these very useful
   slides are also available online at www.ietf.org under "Educational
   Materials".

   The orientation is normally held on Sunday afternoon, along with
   tutorials of interest to newcomers and old-timers alike.  Check the
   agenda for exact times and locations.

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

4.5.  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 meanings shown here.

Top      ToC       Page 17 
   Color     Meaning
   --------------------------------------
   Blue      Working Group/BOF chair
   Green     Host group
   Red       IAB member
   Yellow    IESG member
   Orange    Nominating Committee member

   (Members of the press wear orange-tinted badges.)

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

   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.

4.6.  Terminal Room

   One of the most important (depending on your point of view) things
   the host does is provide Internet access for the meeting attendees.
   In general, wired and wireless 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 that
   donate their equipment, services, and time are to be heartily
   congratulated and thanked.

   Although preparation far in advance of the meeting is encouraged,
   there may be some unavoidable "last minute" things that 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.

   You need to be wearing your badge in order to get into the terminal
   room.  The terminal room provides lots of power strips, lots of
   Ethernet ports for laptops, wireless (for the people who don't need
   Ethernet but want power), usually a printer for public use, and
   sometimes workstations.  What it doesn't provide are terminals; the
   name is historical.  The help desk in the terminal room is a good
   place to ask questions about network failures, although they might
   point you off to different networking staff.

4.7.  Meals and Other Delights

   Marshall Rose once remarked that the IETF was a place to go for "many
   fine lunches and dinners".  Although it is true that some people eat
   very well at the IETF, they find the food on their own; lunches and

Top      ToC       Page 18 
   dinners are not included in the registration fee.  The Secretariat
   does provide appetizers at the Sunday evening reception (not meant to
   be a replacement for dinner), continental breakfast every morning,
   and (best of all) cookies, brownies, and other yummies during
   afternoon breaks.

   If you prefer to get out of the hotel for meals, the local host
   usually provides a list of places to eat within easy reach of the
   meeting site.

4.8.  Social Event

   Another of the most important things organized and managed by the
   host is the IETF social event.  Sometimes, the social event is a
   computer- or high-tech-related event.  At one 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.
   Note, however, that not all IETF meetings have social events.

   Newcomers to the IETF are encouraged to attend the social event.  All
   are encouraged to wear their name tags and leave their laptops
   behind.  The social event is designed to give people a chance to meet
   on a social, rather than technical, level.

4.9.  Agenda

   The agenda for the IETF meetings is a very fluid thing.  It is
   typically sent to the IETF announcement list a few times prior to the
   meeting, and it is also available on the web.  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 printer.  The
   Secretariat will post agenda changes on the bulletin board near the
   IETF registration desk (not the hotel registration desk).  These late
   changes are not capricious: they are made "just in time" as session
   chairs and speakers become aware of unanticipated clashes.  The IETF
   is too dynamic for agendas to be tied down weeks in advance.

   Assignments for breakout rooms (where the Working Groups and BOFs
   meet) and a map showing the room locations are also shown on the
   agenda.  Room assignments can change as the agenda changes.  Some
   Working Groups meet multiple times during a meeting, and every
   attempt is made to have a Working Group meet in the same room for
   each session.

Top      ToC       Page 19 
4.10.  EDU to the Rescue

   If certain aspects of the IETF still mystify you (even after you
   finish reading the Tao), you'll want to drop in on the on-site
   training offered by the Education (EDU) team.  These informal classes
   are designed for newcomers and seasoned IETFers alike.  In addition
   to the Newcomer Training, the EDU team offers workshops for document
   editors and Working Group chairs, plus an in-depth security tutorial
   that's indispensable for both novices and longtime IETF attendees.
   EDU sessions are generally held on Sunday afternoons.  You'll find
   more about the EDU team at http://edu.ietf.org/.

4.11.  Where Do I Fit In?

   The IETF is different things to different people.  There are many
   people who have been very active in the IETF who have never attended
   an IETF meeting.  You should not feel obligated to come to an IETF
   meeting just to get a feel for the IETF.  The following guidelines
   (based on stereotypes of people in various industries) might help you
   decide whether you actually want to come and, if so, what might be
   the best use of your time at your first meeting.

4.11.1.  IS Managers

   As discussed throughout this document, an IETF meeting is nothing
   like any trade show you have attended.  IETF meetings are singularly
   bad places to go if your intention is to find out what will be hot in
   the Internet industry next year.  You can safely assume that going to
   Working Group meetings will confuse you more than it will help you
   understand what is happening, or will be happening, in the industry.

   This is not to say that no one from the industry should go to IETF
   meetings.  As an IS manager, you might want to consider sending
   specific people who are responsible for technologies that are under
   development in the IETF.  As these people read the current Internet
   Drafts and the traffic on the relevant Working Group lists, they will
   get a sense of whether or not their presence would be worthwhile for
   your company or for the Working Groups.

4.11.2.  Network Operators and ISPs

   Running a network is hard enough without having to grapple with new
   protocols or new versions of the protocols with which you are already
   dealing.  If you work for the type of network that is always using
   the very latest hardware and software, and you are following the
   relevant Working Groups in your copious free time, you could
   certainly find participating in the IETF valuable.  A fair amount of
   IETF work also covers many other parts of operations of ISPs and

Top      ToC       Page 20 
   large enterprises, and the input of operators is quite valuable to
   keep this work vibrant and relevant.  Many of the best operations
   documents from the IETF come from real-world operators, not vendors
   and academics.

4.11.3.  Networking Hardware and Software Vendors

   The image of the IETF being mostly ivory tower academics may have
   been true in the past, but the jobs of typical attendees are now in
   industry.  In most areas of the IETF, employees of vendors are the
   ones writing the protocols and leading the Working Groups, so it's
   completely appropriate for vendors to attend.  If you create Internet
   hardware or software, and no one from your company has ever attended
   an IETF meeting, it behooves you to come to a meeting if for no other
   reason than to tell the others how relevant the meeting was or was
   not to your business.

   This is not to say that companies should close up shop during IETF
   meeting weeks so everyone can go to the meeting.  Marketing folks,
   even technical marketing folks, are usually safe in staying away from
   the IETF as long as some of the technical people from the company are
   at the meeting.  Similarly, it isn't required, or likely useful, for
   everyone from a technical department to go, particularly if they are
   not all reading the Internet Drafts and following the Working Group
   mailing lists.  Many companies have just a few designated meeting
   attendees who are chosen for their ability to do complete and useful
   trip reports.  In addition, many companies have internal coordination
   efforts and a standards strategy.  If a company depends on the
   Internet for some or all of its business, the strategy should
   probably cover the IETF.

4.11.4.  Academics

   IETF meetings are often excellent places for computer science folks
   to find out what is happening in the way of soon-to-be-deployed
   protocols.  Professors and grad students (and sometimes overachieving
   undergrads) who are doing research in networking or communications
   can get a wealth of information by following Working Groups in their
   specific fields of interest.  Wandering into different Working Group
   meetings can have the same effect as going to symposia and seminars
   in your department.  Researchers are also, of course, likely to be
   interested in IRTF activities.

4.11.5.  Computer Trade Press

   If you're a member of the press and are considering attending IETF,
   we've prepared a special section of the Tao just for you -- please
   see Section 10.2.

Top      ToC       Page 21 
4.12.  Proceedings

   IETF proceedings are compiled in the two months following each
   meeting and are available on the web and on CD.  Be sure to look
   through a copy -- the proceedings are filled with information about
   IETF that you're not likely to find anywhere else.  For example,
   you'll find snapshots of most WG charters at the time of the meeting,
   giving you a better understanding of the evolution of any given
   effort.

   The proceedings sometimes start with an informative (and highly
   entertaining) message.  Each volume contains the final (hindsight)
   agenda, an IETF overview, area and Working Group reports, and slides
   from the protocol and technical presentations.  The Working Group
   reports and presentations are sometimes incomplete, if the materials
   haven't been turned in to the Secretariat in time for publication.

   An attendee list is also included, which contains names and
   affiliations as provided on the registration form.  For information
   about obtaining copies of the proceedings, see the web listing at
   http://www.ietf.org/proceedings/directory.html.

4.13.  Other General Things

   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.  Bar BOFs
   spring up in many different places around an IETF meeting, such as
   restaurants, coffee shops, and (if we are so lucky) pools.

   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.

Top      ToC       Page 22 
   The IETF meetings, and the plenary session 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, descriptions of online IETF-related
   information).  Please check with the Secretariat before placing
   materials on the desk; the Secretariat has the right to remove
   material that he or she feels is not appropriate.

   If you rely on your laptop during the meeting, it is a good idea to
   bring an extra battery.  It is not always easy to find a spare outlet
   in some meeting rooms, and using the wireless access can draw down
   your battery faster than you might expect.  If you are sitting near a
   power-strip in a meeting room, expect to be asked to plug and unplug
   for others around you.  Many people bring an extension cord with
   spare outlets, which is a good way to make friends with your neighbor
   in a meeting.  If you need an outlet adapter, you should try to buy
   it in advance because the one you need is usually easier to find in
   your home country.



(page 22 continued on part 2)

Next RFC Part