Network Working Group                                          S. Harris
Internet-Draft                                             Merit Network
Expires: April 19, 2005                                       P. Hoffman
                                                          VPN Consortium
                                                        October 19, 2004


  The Tao of IETF - A Novice's Guide to the Internet Engineering Task
                                 Force
                      draft-hoffman-taobis-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on April 19, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes the inner workings of IETF meetings and
   Working Groups, discusses organizations related to the IETF, and
   introduces the standards process.





Harris & Hoffman         Expires April 19, 2005                 [Page 1]


Internet-Draft              The Tao of IETF                 October 2004


Table of Contents

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



Harris & Hoffman         Expires April 19, 2005                 [Page 2]


Internet-Draft              The Tao of IETF                 October 2004


     8.7  Telling It Like It Is -- Using MUST and SHOULD and MAY . .  31
     8.8  Normative References in Standards  . . . . . . . . . . . .  32
     8.9  IANA Considerations  . . . . . . . . . . . . . . . . . . .  33
     8.10   Security Considerations  . . . . . . . . . . . . . . . .  33
     8.11   Patents in IETF Standards  . . . . . . . . . . . . . . .  33
     8.12   Informational and Experimental RFCs  . . . . . . . . . .  34
   9.   How to Contribute to the IETF  . . . . . . . . . . . . . . .  35
     9.1  What You Can Do  . . . . . . . . . . . . . . . . . . . . .  35
     9.2  What Your Company Can Do . . . . . . . . . . . . . . . . .  36
   10.  IETF and the Outside World . . . . . . . . . . . . . . . . .  36
     10.1   IETF and Other Standards Groups  . . . . . . . . . . . .  36
     10.2   Press Coverage of the IETF . . . . . . . . . . . . . . .  37
   11.  Security Considerations  . . . . . . . . . . . . . . . . . .  38
   12.  Informative References . . . . . . . . . . . . . . . . . . .  38
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  39
   A.   Other References . . . . . . . . . . . . . . . . . . . . . .  39
     A.1  Why "The Tao?" . . . . . . . . . . . . . . . . . . . . . .  40
     A.2  Useful E-mail Addresses  . . . . . . . . . . . . . . . . .  40
     A.3  Useful Documents and Files . . . . . . . . . . . . . . . .  41
     A.4  Acronyms and Abbreviations Used in the Tao . . . . . . . .  41
   B.   Changes and additions before this document is finished . . .  43
   C.   Changes since RFC 3160 . . . . . . . . . . . . . . . . . . .  43
     C.1  Changes in -00 . . . . . . . . . . . . . . . . . . . . . .  43
     C.2  Changes in -01 . . . . . . . . . . . . . . . . . . . . . .  44
        Intellectual Property and Copyright Statements . . . . . . .  46


























Harris & Hoffman         Expires April 19, 2005                 [Page 3]


Internet-Draft              The Tao of IETF                 October 2004


1.  Introduction

   Over the last several 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 e-mail messages.

   This document is meant to be part of the FYI series of RFCs, and is
   intended to obsolete FYI 17, RFC 3160.

   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 FYI
   provides the mundane bits of information that newcomers will need in
   order to become active participants.

   Many types of IETF documentation are mentioned in the Tao, from BCPs
   to RFCs and FYIs.  (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;" and
   FYIs provide topical and technical overviews that are introductory or
   appeal to a broad audience.  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.

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 draft are also much appreciated.  Paul
   Hoffman wrote significant portions of this revision and provided
   encouragement, expertise, and much-needed guidance.  Other
   contributors include Scott Bradner, Michael Patton, Donald E.
   Eastlake III, the IETF Secretariat, and members of the User Services
   Working Group.




Harris & Hoffman         Expires April 19, 2005                 [Page 4]


Internet-Draft              The Tao of IETF                 October 2004


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.

   Its mission includes:

   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; and

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

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

   There is no membership in the IETF.  Anyone may register for and
   attend any meeting.  The closest thing there is to being an IETF
   member is being on the IETF or Working Group mailing lists (see
   Section 3.4).  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
   [BCP11], "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.

   One more thing that is important for newcomers: the IETF in no way



Harris & Hoffman         Expires April 19, 2005                 [Page 5]


Internet-Draft              The Tao of IETF                 October 2004


   "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'll 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 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 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.  One in five 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 US.

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's
   oversight of the IETF is remarkably hands-off, so many IETF
   participants don't even know about it.  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



Harris & Hoffman         Expires April 19, 2005                 [Page 6]


Internet-Draft              The Tao of IETF                 October 2004


   wants to say something to the press.  The ISOC is one of the major
   unsung (and under-funded) heroes of the Internet.

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.
   The IESG ratifies or corrects the output from the IETF's Working
   Groups, 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 "Nomcom") and are
   appointed for two years.  The process for choosing the members of the
   IESG is detailed in BCP 10 [BCP10], "IAB and IESG Selection,
   Confirmation, and Recall Process:  Operation of the Nominating and
   Recall Committees."

   The current areas and abbreviations are shown in Table 1.

   +---------------------------------+---------------------------------+
   | Area                            | Description                     |
   +---------------------------------+---------------------------------+
   | Applications (APP)              | Protocols seen by user          |
   |                                 | programs, such as e-mail and    |
   |                                 | the Web                         |
   | General (GEN)                   | Catch-all for WGs that don't    |
   |                                 | fit in other areas (which is    |
   |                                 | very few)                       |
   | Internet (INT)                  | Different ways of moving IP     |
   |                                 | packets and DNS information     |
   | Operations and Management (OPS) | Operational aspects, network    |
   |                                 | monitoring, and configuration   |
   | Routing (RTG)                   | Getting packets to their        |
   |                                 | destinations                    |
   | Security (SEC)                  | Authentication and privacy      |
   | Transport (TSV)                 | Special services for special    |
   |                                 | packets                         |
   +---------------------------------+---------------------------------+

                          Table 1: IETF areas

   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 an Area



Harris & Hoffman         Expires April 19, 2005                 [Page 7]


Internet-Draft              The Tao of IETF                 October 2004


   Director 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 discusses each Internet Draft that is proposed
   to become an RFC.  At least two IESG members must express concerns
   before a draft can be blocked from moving forward.  These checks 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.

   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 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 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 has 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 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 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 brings these topics
   to the attention of people they think should know about them.

   IAB members pay special attention to emerging activities in the IETF.



Harris & Hoffman         Expires April 19, 2005                 [Page 8]


Internet-Draft              The Tao of IETF                 October 2004


   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 the ISOC

   o  Oversees IETF liaisons with other standards bodies


   Like the IESG, the IAB members are selected for multi-year positions
   by the Nomcom, and are approved by the Board of Trustees of the ISOC.

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.

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



Harris & Hoffman         Expires April 19, 2005                 [Page 9]


Internet-Draft              The Tao of IETF                 October 2004


   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 ISOC and can be contacted by
   e-mail at <mailto:rfc-editor@rfc-editor.org>.

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 for helping the IESG do its work.  The IETF Secretariat is
   financially supported by the fees of the face-to-face meetings.

3.3  Are Changes Coming?

   Like many flourishing organizations, the IETF has experienced a few
   growing pains over the years.  The volume of work brought to the IETF
   has increased at what seems to approach the speed of light, and
   management and administrative structures have sometimes had a hard
   time keeping up.

   IETFers have never been shy about expressing their opinions, and they
   haven't hesitated to voice their concerns about the need for improved
   policies and procedures.  Formal efforts to evaluate and fix the
   perceived problems began at the Yokohama meeting in July 2002, when



Harris & Hoffman         Expires April 19, 2005                [Page 10]


Internet-Draft              The Tao of IETF                 October 2004


   Working Groups were set up to deal with issues ranging from
   procedural delays to the need for an IETF mission statement.  If you
   want to catch up on the discussions so far, see RFC 3774 [RFC3774],
   "IETF Problem Statement," and RFC 3844 [RFC3844], "IETF Problem
   Resolution Process."  If you are curious about the current status of
   change efforts, keep an eye on the IETF mailing list, which is
   discussed in the next section, and stay tuned!

3.4  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 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>,
   announces each new version of every Internet Draft as it is
   published.

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

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

   Do not, ever, under any circumstances, for any reason, send a request
   to join a list to the list itself!  The thousands of people on the
   list don't need, or want, to know when a new person joins.
   Similarly, when changing 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,



Harris & Hoffman         Expires April 19, 2005                [Page 11]


Internet-Draft              The Tao of IETF                 October 2004


   it is not a place for companies or individuals to solicit or
   advertise, as noted in BCP45 [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.

   Only the Secretariat 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 dweebfests 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, although ISOC kicks in
   additional funds for things like the multicast simulcast 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 or two.  The past few meetings
   have had about 2,500 attendees.  There have been more than 60 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 half the people in a WG meeting reading
   e-mail or perusing the web during presentations they find
   uninteresting.



Harris & Hoffman         Expires April 19, 2005                [Page 12]


Internet-Draft              The Tao of IETF                 October 2004


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 e-mail 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 breaks.

   Credit card payments on the web are encrypted and secure, or, if you
   prefer, you can use 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, beginning at noon on Sunday and continuing throughout
   the 5:00 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.
   Attendees who pre-paid will also find their receipt in their packet.
   It's worth noting that neither attendee names and addresses or IETF
   mailing lists are ever offered for sale.

   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



Harris & Hoffman         Expires April 19, 2005                [Page 13]


Internet-Draft              The Tao of IETF                 October 2004


   registration", they almost always mean the IETF registration desk,
   not the hotel registration desk.

4.2  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 is typically
   about 30 minutes long and 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' Orientation 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.  The Standards Process Orientation also
   lasts about 30 minutes.

   There is ample time at the end for questions.  The Secretariat also
   provides handouts that include an overview of the IETF, a list of
   important files available online, and 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 "Additional Information".

   The orientation is held on Sunday afternoon before the 5:00 p.m.
   reception (check the agenda for exact time and location).  Be advised
   that attending the orientation does NOT mean you can go to the
   reception early!

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

4.4  Seeing Spots Before Your Eyes

   Some of the people at the IETF will have a little colored dot on



Harris & Hoffman         Expires April 19, 2005                [Page 14]


Internet-Draft              The Tao of IETF                 October 2004


   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 in Table 2.

                +--------+-----------------------------+
                | Color  | Meaning                     |
                +--------+-----------------------------+
                | Blue   | Working Group/BOF chair     |
                | Green  | Host group                  |
                | Red    | IAB member                  |
                | Yellow | IESG member                 |
                | Orange | Nominating Committee member |
                +--------+-----------------------------+

                                Table 2

   (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.5  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 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 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.  The helpdesk in the terminal room is a good
   place to ask questions about network failures, although they might



Harris & Hoffman         Expires April 19, 2005                [Page 15]


Internet-Draft              The Tao of IETF                 October 2004


   point you off to different networking staff.

4.6  Meals and Other Delights

   Marshall Rose once remarked that the IETF was a place to go for "many
   fine lunches and dinners."  While it is true that some people eat
   very well at the IETF, they find the food on their own; lunches and
   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.7  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.
   Everyone is 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.8  Agenda

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

   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.



Harris & Hoffman         Expires April 19, 2005                [Page 16]


Internet-Draft              The Tao of IETF                 October 2004


4.9  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 for 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.10  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.10.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 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.10.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 might find
   attending the IETF meeting valuable.  The closer you are to the
   bleeding edge of networking, particularly in the areas of routing and



Harris & Hoffman         Expires April 19, 2005                [Page 17]


Internet-Draft              The Tao of IETF                 October 2004


   switching, the more likely it is that you will be able to learn and
   contribute at an IETF meeting.

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

4.10.4  Academics

   IETF meetings are often excellent places for computer science folk 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.

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

4.11  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



Harris & Hoffman         Expires April 19, 2005                [Page 18]


Internet-Draft              The Tao of IETF                 October 2004


   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 of 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, and contains names, affiliations,
   work and fax phone numbers, and e-mail addresses 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.12  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.

   The IETF, 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.



Harris & Hoffman         Expires April 19, 2005                [Page 19]


Internet-Draft              The Tao of IETF                 October 2004


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

   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.

5.  Working Groups

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

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

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

5.1  Working Group Chairs

   The role of the WG chairs is described in both BCP 11 [BCP11] and BCP
   25 [BCP25].  The IETF EDU team also offers special training for WG
   chairs on Sunday afternoons preceding IETF.  Basically, their job is



Harris & Hoffman         Expires April 19, 2005                [Page 20]


Internet-Draft              The Tao of IETF                 October 2004


   to keep the discussion moving forward towards the milestones in the
   WG charter -- 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 Working Group chairs are much better at
   their jobs than others.  When a WG has fulfilled its charter, it is
   supposed to cease operations.  (Most WG mailing lists continue on
   after a WG is closed, still discussing the same topics as the Working
   Group did.)  In the IETF, it is a mark of success that the WG closes
   up because it fulfilled its charter.  This is one of the aspects of
   the IETF that newcomers who have experience with other standards
   bodies have a hard time understanding.  However, some WG chairs never
   manage to get their WG to finish, or keep adding new tasks to the
   charter so that the Working Group drags on for many years.  The
   output of these aging WGs is often not nearly as useful as the
   earlier products, and the messy results are sometimes 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, take a look at the slides at
   http://www.ietf.org/IESG/WG-Train.pdf.

5.2  Getting Things Done in a Working Group

   One fact that confuses many novices is that the face-to-face WG
   meetings are much less important in the IETF than they are in most
   other organizations.  Any decision made at a face-to-face meeting
   must also gain consensus on the WG mailing list.  There are numerous
   examples of important decisions made in WG meetings that are later
   overturned on the mailing list, often because someone who couldn't
   attend the meeting pointed out a serious flaw in the logic used to
   come to the decision.

   Another aspect of Working Groups that confounds many people is the
   fact that there is no formal voting.  The general rule on disputed
   topics is that the Working Group has to come to "rough consensus,"
   meaning that a very large majority of those who care must agree.  The
   exact method of determining rough consensus varies from Working Group



Harris & Hoffman         Expires April 19, 2005                [Page 21]


Internet-Draft              The Tao of IETF                 October 2004


   to Working Group.  Sometimes consensus is determined by "humming" --
   if you agree with a proposal, you hum when prompted by the chair; if
   you disagree, you keep your silence.  Newcomers find it quite
   peculiar, but it works.

   The lack of formal voting has caused some very long delays for some
   proposals, but most IETF participants who have witnessed rough
   consensus after acrimonious debates feel that the delays often result
   in better protocols.  (And, if you think about it, how could you have
   "voting" in a group that anyone can join, and when it's impossible to
   count the participants?)

   Some Working Groups have complex documents or a complex set of
   documents (or even both!).  Shaking all the bugs out of one or more
   complex documents is a daunting task.  In order to help relieve this
   problem, some working groups use "issue trackers", which are online
   lists of the open issues with the documents, the status of the issue,
   proposed fixes, and so on.  Using an issue tracker not only helps the
   WG not to forget to do something important, it can help remind
   everyone when someone asks a question later about why something was
   done in a particular fashion.

   Another method that some Working Groups adopt is to have a Working
   Group "secretary" to handle the juggling of the documents and the
   changes.  The secretary can run the issue tracker if there is one, or
   can simply be in charge of watching that all of the decisions that
   are made on the mailing list are reflected in newer versions of the
   the documents.

   One thing you might find helpful, and possibly even entertaining,
   during Working Group sessions is to follow the running commentary on
   Jabber.  The running commentary is often used as the minutes of the
   meeting, but it can also include jokes, sighs, and other extraneous
   chatter.  Jabber is a free, streaming XML technology mainly used for
   instant messaging.  You can find pointers to Jabber clients for many
   platforms at http://www.jabber.org.

5.3  Preparing for Working Group Meetings

   The most important thing that everyone (newcomers and seasoned
   experts) should do before coming to a face-to-face meeting is to read
   the Internet Drafts and RFCs beforehand.  WG meetings are explicitly
   not for education:  they are for developing the group's documents.
   Even if you do not plan to say anything in the meeting, you should
   read the group's documents before attending so you can understand
   what is being said.

   It's up to the WG chair to set the meeting agenda, usually a few



Harris & Hoffman         Expires April 19, 2005                [Page 22]


Internet-Draft              The Tao of IETF                 October 2004


   weeks in advance.  If you want something discussed at the meeting, be
   sure to let the chair know about it.  The agendas for all the WG
   meetings are available in advance (see
   http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the
   meeting number), but many WG chairs are lax (if not totally
   negligent) about turning them in.

   The Secretariat only schedules WG meetings a few weeks in advance,
   and the schedule often changes as little as a week before the first
   day.  If you are only coming for one WG meeting, you may have a hard
   time booking your flight with such little notice, particularly if the
   Working Group's meeting changes schedule.  Be sure to keep track of
   the current agenda so you can schedule flights and hotels.  But, when
   it comes down to it, you probably shouldn't be coming for just one WG
   meeting.  It's likely that your knowledge could be valuable in a few
   WGs, assuming that you've read the drafts and RFCs for those groups.

   If you're giving a presentation at a face-to-face meeting, you should
   probably come with a few slides prepared.  Projectors for laptop-
   based presentations are available in all the meeting rooms.  And
   here's a tip for your slides:  don't put your company's logo on every
   one, even though it's common practice outside the IETF.  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.

5.4  Working Group Mailing Lists

   As we mentioned earlier, the IETF announcement and discussion mailing
   lists are the central mailing lists for IETF activities.  However,
   there are many other mailing lists related to IETF work.  For
   example, every Working Group has its own discussion list.  In
   addition, there are some long-term technical debates that have been
   moved off of the IETF list onto lists created specifically for those
   topics.  It is highly recommended that everybody follow the
   discussions on the mailing lists of the Working Groups that 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 can't attend the
   IETF meetings.

   Many IETF discussion lists use either mailman or another list
   manager, Majordomo.  They usually have a "-request" address which
   handles the administrative details of joining and leaving the list.



Harris & Hoffman         Expires April 19, 2005                [Page 23]


Internet-Draft              The Tao of IETF                 October 2004


   (See Section 3.4 for more information on mailman.)  It is generally
   frowned upon when such administrivia appears on the discussion
   mailing list.

   Most IETF discussion lists are archived.  That is, all of the
   messages sent to the list are automatically stored on a host for
   anonymous FTP access.  Many such archives are listed online at
   ftp://ftp.ietf.org/ietf-mail-archive/.  If you don't find the list
   you're looking for, send a message to the list's "-request" address
   (not to the list itself!).

5.5  Interim Working Group Meetings

   Working groups sometimes hold interim meetings between IETFs.
   Interim meetings aren't a substitute for IETF meetings, however -- a
   group can't decide to skip a meeting in a location they're not fond
   of and meet in Cancun (or even someplace mundane) three weeks later,
   for example.  Interim meetings require AD approval, and need to be
   announced at least one month in advance.  Location and timing need to
   allow fair access for all participants.  Like regular IETF meetings,
   someone needs to take notes and send them to
   <mailto:proceedings@ietf.org>, and the group needs to take
   attendance.

6.  BOFs

   In order to form a Working Group, you need a charter and someone who
   is able to be chair.  In order to get those things, you need to get
   people interested so that they can help focus the charter and
   convince an Area Director that the project is worthwhile.  A
   face-to-face meeting is useful for this.  In fact, very few WGs get
   started by an Area Director; most start after a face-to-face BOF
   because attendees have expressed interest in the topic.

   A BOF meeting has to be approved by the Area Director in the relevant
   area before it can be scheduled.  If you think you really need a new
   WG, approach an AD informally with your proposal and see what they
   think.  The next step is to request a meeting slot at the next
   face-to-face meeting.  Of course, you don't need to wait for that
   meeting to get some work done, such as setting up a mailing list and
   starting to discuss a charter.

   BOF meetings have a very different tone than 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.




Harris & Hoffman         Expires April 19, 2005                [Page 24]


Internet-Draft              The Tao of IETF                 October 2004


   An advantage of having a draft before the BOF is to help focus the
   discussion.  On the other hand, having a draft might tend to limit
   what the other folks in the BOF want to do in the charter.  It's
   important to remember that most BOFs are held in order to get support
   for an eventual Working Group, not to get support for a particular
   document.

   Many BOFs don't turn into WGs for a variety of reasons.  A common
   problem is that not enough people can agree on a focus for the work.
   Another typical reason is that the work wouldn't end up being a
   standard -- if, for example, the document authors don't really want
   to relinquish change control to a WG.  (We'll discuss change control
   later in this document.)  Only two meetings of a BOF can be scheduled
   on a particular subject; either a WG has to form, or the topic should
   be dropped.

7.  ** New to the IETF? STOP HERE! (Temporarily) **

   If you're new to the IETF and this is the only reference you plan to
   read before coming to the meeting, stop here -- at least temporarily.
   Then, on your flight home, read the rest of the Tao.  By that time
   you'll be ready to get actively involved in the Working Groups that
   interested you at the meeting, and the Tao will get you started on
   your way.

8.  RFCs and Internet Drafts

   If you're a new IETF participant and are looking for a particular RFC
   or Internet Draft, go to the RFC Editor's Web pages,
   http://www.rfc-editor.org/rfc.html.  That site also has links to
   other RFC collections, many with search capabilities.  If you know
   the number of the RFC you're looking for, go to the IETF RFC pages,
   http://www.ietf.org/rfc.html.  For Internet Drafts, the best resource
   is the IETF web site, http://www.ietf.org/ID.html, where you can
   search by title and keyword.

8.1  Getting a Standard Published

   One of the most common questions seasoned IETFers hear from newcomers
   is, "How do I get an IETF standard published?"  A much better
   question is, "Should I write an IETF standard?" since the answer is
   not always "yes."  If you do decide to try to write a document that
   becomes an IETF standard, be warned that the overall process may be
   arduous, even if the individual steps are fairly straightforward.
   Lots of people get through the process unscathed, though, and there's
   plenty of written guidance that helps authors emerge with their ego
   more or less intact.




Harris & Hoffman         Expires April 19, 2005                [Page 25]


Internet-Draft              The Tao of IETF                 October 2004


   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:

   1.  Publish the document as an Internet Draft

   2.  Receive comments on the draft

   3.  Edit your draft based on the comments

   4.  Repeat steps 1 through 3 a few times

   5.  Ask an Area Director to take the draft to the IESG (if it's an
       individual submission).  If the draft is an official Working
       Group product, the WG chair asks the AD to take it to the IESG.

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

   7.  Wait for the document to be published by the RFC Editor

   A much more complete explanation of these steps is contained in BCP 9
   [BCP9], "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 rankings.  There are
   six kinds of RFCs:

   o  Proposed standards

   o  Draft standards

   o  Internet standards (sometimes called "full standards")

   o  Experimental protocols

   o  Informational documents

   o  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 [RFC1796], "Not All RFCs are Standards."




Harris & Hoffman         Expires April 19, 2005                [Page 26]


Internet-Draft              The Tao of IETF                 October 2004


   There are also three sub-series of RFCs, known as FYIs, BCPs, and
   STDs.  The For Your Information RFC sub-series was created to
   document overviews and topics which are introductory or appeal to a
   broad audience.  Best Current Practice documents describe the
   application of various technologies in the Internet.  The STD RFC
   sub-series was created to identify RFCs that do in fact specify
   Internet standards.  Some STDs are actually sets of more than one
   RFC, and the "standard" designation applies to the whole set of
   documents.

8.2  Letting Go Gracefully

   The biggest reason some people do not want their documents put on the
   IETF standards track is that they must give up change control of the
   protocol.  That is, as soon as you propose that your protocol become
   an IETF standard, you must fully relinquish control of the protocol.
   If there is general agreement, parts of the protocol can be
   completely changed, whole sections can be ripped out, new things can
   be added, and the name can be changed.

   Some authors find it very hard to give up control of their pet
   protocol.  If you are one of those people, don't even think about
   trying to get your protocol to become an IETF standard.  On the other
   hand, if your goal is the best standard possible with the widest
   implementation, then you might find the IETF process to your liking.

   Incidentally, the change control on Internet standards doesn't end
   when the protocol is put on the standards track.  The protocol itself
   can be changed later for a number of reasons, the most common of
   which is that implementors discover a problem as they implement the
   standard.  These later changes are also under the control of the
   IETF, not the editors of the standards document.

   IETF standards exist so that people will use them to write Internet
   programs that interoperate.  They don't exist to document the
   (possibly wonderful) ideas of their authors, nor do they exist so
   that a company can say "we have an IETF standard."  If a standards-
   track RFC only has one implementation (whereas two are required for
   it to advance on the standards track), it was probably a mistake to
   put it on the standards track in the first place.

8.3  Internet Drafts

   First things first.  Every document that ends up in the RFC
   repository starts life as an Internet Draft.  Internet Drafts are
   tentative documents -- they're meant for readers to comment on, so
   authors can mull over those comments and decide which ones to
   incorporate in the draft.  In order to remind folks of their



Harris & Hoffman         Expires April 19, 2005                [Page 27]


Internet-Draft              The Tao of IETF                 October 2004


   tentativeness, Internet Drafts are automatically removed from the
   online directories after six months.  They are most definitely not
   standards or even specifications.  As BCP 9 [BCP9] says:

   An Internet Draft is NOT a means of "publishing" a specification;
   specifications are published through the RFC mechanism ...  Internet
   Drafts have no formal status, and are subject to change or removal at
   any time.  Under no circumstances should an Internet Draft be
   referenced by any paper, report, or Request-for-Proposal, nor should
   a vendor claim compliance with an Internet Draft.

   You can always tell a person who doesn't understand the IETF (or is
   intentionally trying to fool people) when 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
   [RFC2223], "Instructions to RFC Authors," describes the nroff
   formatting used by the RFC Editor.

   An Internet Draft can be either a Working Group draft or an
   individual submission.  Working Group drafts are usually reviewed by
   the chair before being accepted as a WG item.

   If you're interested in checking the status of a particular draft, or
   can't remember its exact name, or want to find out which drafts a WG
   is working on, try out the handy "I-D Tracker" at
   https://datatracker.ietf.org/public/pidtracker.cgi.  The I-D tracker
   is especially useful for authors who want to track the progress of
   their draft as it makes its way through the publication process.

   There are some informal rules for Internet Draft naming that have
   evolved over the years.  Internet Drafts that revise existing RFCs
   often have draft names with "bis" in them, meaning "the thing after
   the RFC"; for example, a draft might be called
   "draft-someone-rfc2345bis-00.txt".

8.4  Recommended Reading for Writers

   Before you create the first draft of your Internet Draft, you should
   read four documents:

   o  More important than just explaining formatting, RFC 2223
      [RFC2223], also explains what needs to be in an Internet Draft
      before it can become an RFC.  This document describes all the



Harris & Hoffman         Expires April 19, 2005                [Page 28]


Internet-Draft              The Tao of IETF                 October 2004


      sections and notices that will need to be in your document, and
      it's good to have them there from the beginning so that readers
      aren't surprised when you put them in later versions.

   o  BCP 22 [BCP22], "Guide for Internet Standards Writers," provides
      tips that will help you write a standard that leads to
      interoperability.  For instance, it explains how to choose the
      right number of protocol options, how to respond to out-of-spec
      behavior, and how to show state diagrams.

   o  The online "Guidelines to Authors of Internet Drafts,"
      http://www.ietf.org/ietf/1id-guidelines.txt, 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.

   o  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,"
      http://www.ietf.org/ID-nits.html, a list of common "nits" that
      have been known to stop documents in 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.

8.5  Filenames and Other Matters

   When you're ready to turn in your Internet Draft, send it to the
   Internet Drafts editor at <mailto:internet-drafts@ietf.org>.  There
   is a real person at the other end of this mail address -- their job
   is to make sure you've included the minimum items you need for the
   Internet Draft to be published.  When you submit the first version of
   the draft, the draft editor supplies the filename 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's 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 someone named Smith wrote might
   be named "draft-smith-keying-00.txt".  If a draft is an individual
   submission but relates to a particular working group, the author
   sometimes follows their name with the name of the working group, such
   as "draft-smith-smime-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 filename.




Harris & Hoffman         Expires April 19, 2005                [Page 29]


Internet-Draft              The Tao of IETF                 October 2004


   After the first edition of a draft, the number in the filename is
   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 filename changes after the first version,
   such as when a personal effort is pulled into a Working Group.

8.6  Standards-Track RFCs

   The procedure for creating and advancing a standard is described in
   BCP 9 [BCP9].  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 the 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 when 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 submissions.

   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 of 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's 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.




Harris & Hoffman         Expires April 19, 2005                [Page 30]


Internet-Draft              The Tao of IETF                 October 2004


   Don't be surprised if a particular standard doesn't progress from
   Proposed to Draft.  In fact, most of the standards in common use are
   Proposed Standards and never move forward.  This may be because no
   one took 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 everyone found more important things to do.

   A few years after a document has been a Draft Standard, it can become
   an 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 goes over
   the document with a fine-tooth comb before making a Draft Standard an
   Internet Standard.

8.7  Telling It Like It Is -- 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 way to make it more likely that developers will create
   interoperable implementations of standards is to be clear about
   what's being mandated in a specification.  Early RFCs used all kinds
   of expressions to explain what was needed, so implementors didn't
   always know which parts were suggestions and which were requirements.
   As a result, standards writers in the IETF generally agreed to limit
   their wording to a few specific words with a few specific meanings.

   STD 3 [STD3] (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
   [BCP14], "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're using the
   definitions from BCP 14, you should do two things.  First, refer to
   BCP 14 (although most people refer to it as RFC 2119, because that's
   what BCP 14 tells you to do), so that the reader knows how you're
   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



Harris & Hoffman         Expires April 19, 2005                [Page 31]


Internet-Draft              The Tao of IETF                 October 2004


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

8.8  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 we noted 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 could 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
   generally this 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, as with a designation of the date of
   the standard.  Some external standards bodies don't 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



Harris & Hoffman         Expires April 19, 2005                [Page 32]


Internet-Draft              The Tao of IETF                 October 2004


   the WG chair or appropriate Area Director if a particular external
   standard can be used in an IETF standard.

8.9  IANA Considerations

   More and more IETF standards require the registration of various
   protocol parameters, such as named options in the protocol.  As we
   noted in Section 3.2.4, the main registry for all IETF standards has
   long been IANA.  Because of the large and diverse kinds of registries
   that standards require, IANA needs to have specific information about
   how to register 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 [BCP26], 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.

8.10  Security Considerations

   One thing that's required in every RFC is a "Security Considerations"
   section.  This section should describe any known vulnerabilities of
   the protocol, possible threats, and mechanisms or strategies to
   address them.  Don't gloss over this section -- in particular, don't
   say "here's our protocol, if you want security, just use IPSEC".
   This won't do at all, because it doesn't answer the question of how
   IPSEC interacts with your protocol, and vice versa.  Be sure to check
   with your Working Group chair if you're not sure how to handle this
   section in your draft.

8.11  Patents in IETF Standards

   [[ IPR is currently being worked on in the IETF; this section will be
   updated in future versions.  ]]

   The problems of intellectual property have cropped up more and more
   often 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.  Not surprisingly, then, 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's a patent on



Harris & Hoffman         Expires April 19, 2005                [Page 33]


Internet-Draft              The Tao of IETF                 October 2004


   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 [BCP9], 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).

   If you are writing an Internet Draft and you know of a patent that
   applies to the technology you're writing about, don't list the patent
   in the document.  Instead, send a note to the IETF Secretariat
   (<mailto:iesg-secretaryt@ietf.org>) about the patent or other
   intellectual property rights.  The note will be published on the IETF
   IPR web page (http://www.ietf.org/ipr.html).  Intellectual property
   rights aren't mentioned in RFCs because RFCs never change after they
   are published, but knowledge of IPR can change at any time.
   Therefore, an IPR list in a RFC could be incomplete and mislead the
   reader.  BCP 9 [BCP9] provides specific text that should be added to
   RFCs where the author knows of IPR issues.

8.12  Informational and Experimental RFCs

   As we noted earlier, not all RFCs are standards.  In fact, plenty of
   important RFCs are not on the standards track at all.  Currently,
   there are two designations for RFCs that are not meant to be
   standards:  Informational, like the Tao, and Experimental.  (There is
   actually a third designation, Historical, but that is reserved for
   documents that were on the 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



Harris & Hoffman         Expires April 19, 2005                [Page 34]


Internet-Draft              The Tao of IETF                 October 2004


   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.

9.  How to Contribute to the IETF

9.1  What You Can Do

   '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 become more widespread 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 to
   get 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.






Harris & Hoffman         Expires April 19, 2005                [Page 35]


Internet-Draft              The Tao of IETF                 October 2004


9.2  What Your Company Can Do

   'Share' --  Avoid proprietary standards.  If you are an implementor,
   exhibit a strong preference for IETF standards.  If the IETF
   standards aren't as good as the proprietary standards, work to make
   the IETF standards better.  If you're 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.

   'Open Up' --  If your company controls a patent that is used in an
   IETF standard, 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 a lot of 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.

10.  IETF and the Outside World

10.1  IETF and 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-



Harris & Hoffman         Expires April 19, 2005                [Page 36]


Internet-Draft              The Tao of IETF                 October 2004


   IEC/JTC1 (The Joint Technical Committee of the International
   Organization for Standardization and International Electrotechnical
   Commission).  The list of IETF liaisons, www.ietf.org/ietf/1iesg-
   liaisons.txt, shows that there are many different liaisons to ISO-
   IEC/JTC1 subcommittees.

10.2  Press Coverage of the IETF

   Given that the IETF is one of the best-known bodies that is helping
   move the Internet forward, it's natural for the computer press (and
   even the trade press) to want to cover its actions.  In recent years,
   a small number of magazines have assigned reporters and editors to
   cover the IETF in depth over a long period of time.  These reporters
   have ample scars from articles that they got wrong, incorrect
   statements about the status of Internet Drafts, quotes from people
   who are unrelated to the IETF work, and so on.

   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 could straighten them out, such as a WG chair or an
   Area Director.  The official press contact for the IETF is the IETF
   Secretariat.

   The fact that those reporters who've gotten it wrong once come back
   to IETF meetings shows that it is possible to get it right
   eventually.  However, IETF meetings are definitely not for reporters
   who are naive about the IETF process (although if you are a reporter
   the fact that you are reading this document is a very good sign!).
   Further, if you think that you'll get a hot story from attending an
   IETF meeting, you are likely to be disappointed.

   Considering all this, it's not surprising that some IETFers would
   prefer to have the press stay as far away from meetings as possible.
   Having a bit of press publicity for protocols that are almost near
   completion and will become significant in the industry in the next
   year can be a good thing.  However, it is the rare reporter who can
   resist over-hyping a nascent protocol as the next savior for the
   Internet.  Such stories do much more harm than good, both for the
   readers of the article and for the IETF.

   The main reason why a reporter might want to attend an IETF meeting
   is not to cover hot technologies (since that can be done in the



Harris & Hoffman         Expires April 19, 2005                [Page 37]


Internet-Draft              The Tao of IETF                 October 2004


   comfort of your office by reading the mailing lists), but to meet
   people face to face.  Unfortunately, the most interesting people are
   the ones who are also the busiest during the IETF meeting, and some
   folks have a tendency to run away when they see a press badge.
   However, IETF meetings are excellent places to meet and speak with
   document authors and Working Group chairs; this can be quite valuable
   for reporters who are covering the progress of protocols.

   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's 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.

11.  Security Considerations

   Section 8.11 explains why each RFC is required to have a Security
   Considerations section, and gives some idea of what it should and
   should not contain.  Other than that information, this document does
   not touch on Internet security.

12  Informative References

   [BCP9]     Bradner, S., "The Internet  Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [BCP10]    Galvin, J., "IAB and IESG Selection, Confirmation, and
              Recall  Process: Operation of the Nominating and Recall
              Committees", BCP 10, RFC 3777, June 2004.

   [BCP11]    Hovey, R. and S. Bradner, "The Organizations Involved  in
              the IETF Standards Process", BCP 11, RFC 2028, October
              1996.

   [BCP14]    Bradner, S., "Key words for use in RFCs to  Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [BCP22]    Scott, G., "Guide for Internet Standards Writers", BCP 22,
              RFC 2360, June 1998.




Harris & Hoffman         Expires April 19, 2005                [Page 38]


Internet-Draft              The Tao of IETF                 October 2004


   [BCP25]    Bradner, S., "IETF Working Group Guidelines  and
              Procedures", BCP 25, RFC 2418, September 1998.

   [BCP26]    Narten, T. and H. Alvestrand, "Guidelines  for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [BCP45]    Harris, S., "IETF Discussion List Charter", BCP 45, RFC
              3005, November 2000.

   [RFC1796]  Huitema, C., Postel, J. and S. Crocker, "Not All RFCs are
              Standards", RFC 1796, April 1995.

   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
              RFC 2223, October 1997.

   [RFC3774]  Davies, E., "IETF Problem Statement", RFC 3774, May 2004.

   [RFC3844]  Davies, E. and J. Hofmann, "IETF Problem Resolution
              Process", RFC 3844, August 2004.

   [STD3]     Braden, R., "Requirements for Internet Hosts - Application
              and  Support", STD 3, RFC 1123, October 1989.


Authors' Addresses

   Susan Harris
   Merit Network
   4251 Plymouth Road, Suite 2000
   Ann Arbor, MI  48105
   US

   EMail: srh@merit.edu


   Paul Hoffman
   VPN Consortium
   127 Segre Place
   Santa Cruz, CA  95060
   US

   EMail: paul.hoffman@vpnc.org

Appendix A.  Other References






Harris & Hoffman         Expires April 19, 2005                [Page 39]


Internet-Draft              The Tao of IETF                 October 2004


A.1  Why "The Tao?"

   Pronounced "dow", Tao is the basic principle behind the teachings of
   Lao-tse, a Chinese master.  Its familiar symbol is the black and
   white Yin-Yang circle.  Taoism conceives the universe as a single
   organism, and human beings as interdependent parts of a cosmic whole.
   Tao is sometimes translated "the way," but according to Taoist
   philosophy the true meaning of the word cannot be expressed in words.

A.2  Useful E-mail Addresses

   Some useful e-mail addresses are listed in Table 3.  These addresses
   may change from time to time, and it's a good idea to check the IETF
   Web pages for the correct address before sending your mail.

   +---------------------------------+---------------------------------+
   | Address                         | Description                     |
   +---------------------------------+---------------------------------+
   | <mailto:agenda@ietf.org>        | Requests for agenda slots at    |
   |                                 | IETF meetings                   |
   | <mailto:ietf-action@ietf.org>   | Requests for things to be done  |
   |                                 | when you don't know exactly     |
   |                                 | where to send the request       |
   | <mailto:ietf-info@ietf.org>     | General questions about the     |
   |                                 | IETF                            |
   | <mailto:ietf-registrar@ietf.org | Questions about registration,   |
   |                                 | meeting locations, and fees     |
   | <mailto:ietf-request@ietf.org>  | Requests to join/leave IETF     |
   |                                 | lists                           |
   | <mailto:ietg-secretary@ietf.org | Questions for the Secretariat   |
   |                                 |                                 |
   | <mailto:ietf-web@ietf.org>      | Web questions/comments          |
   | <mailto:internet-drafts@ietf.or | Internet Draft submissions and  |
   | >                               | queries                         |
   | <mailto:proceedings@ietf.org>   | Where to send Working Group     |
   |                                 | minutes and slides for the IETF |
   |                                 | Proceedings                     |
   | <mailto:iana@iana.org>          | Internet Assigned Numbers       |
   |                                 | Authority                       |
   | <mailto:rfc-editor@rfc-editor.o | RFC Editor                      |
   | g>                              |                                 |
   +---------------------------------+---------------------------------+

                    Table 3: Useful email addresses







Harris & Hoffman         Expires April 19, 2005                [Page 40]


Internet-Draft              The Tao of IETF                 October 2004


A.3  Useful Documents and Files

   The IETF web site, http://www.ietf.org, is the best source for
   information about meetings, Working Groups, Internet Drafts, RFCs,
   IETF e-mail addresses, and much more.  Click on "Additional
   Information" to find a variety of helpful links.  Internet Drafts and
   other documents are also available in the "ietf" directory on
   anonymous FTP sites worldwide.  For a listing of these sites, see:
   http://www.ietf.org/shadow.html

   Check the IESG web pages, http://www.ietf.org/iesg.html, to find
   up-to-date information about drafts processed, RFCs published, and
   documents in Last Call, as well as the monthly IETF status reports.

A.4  Acronyms and Abbreviations Used in the Tao

   Some of the acronyms and abbreviations from this document are listed
   in Table 4.

































Harris & Hoffman         Expires April 19, 2005                [Page 41]


Internet-Draft              The Tao of IETF                 October 2004


   +---------------------------------+---------------------------------+
   | Term                            | Meaning                         |
   +---------------------------------+---------------------------------+
   | AD                              | Area Director                   |
   | BCP                             | Best Current Practice           |
   | BOF                             | Birds Of a Feather              |
   | FAQ                             | Frequently Asked Question(s)    |
   | FYI                             | For Your Information (RFC)      |
   | IAB                             | Internet Architecture Board     |
   | IANA                            | Internet Assigned Numbers       |
   |                                 | Authority                       |
   | ICANN                           | Internet Corporation for        |
   |                                 | Assigned Names and Numbers,     |
   |                                 | http://www.icann.org/           |
   | I-D                             | Internet Draft                  |
   | IESG                            | Internet Engineering Steering   |
   |                                 | Group,                          |
   |                                 | http://www.ietf.org/iesg.html   |
   | IETF                            | Internet Engineering Task       |
   |                                 | Force, http://www.ietf.org/     |
   | INET                            | Internet Society Conference,    |
   |                                 | http://www.isoc.org/isoc/confer |
   |                                 | nces/inet/                      |
   | IRTF                            | Internet Research Task Force,   |
   |                                 | http://www.irtf.org/            |
   | ISO                             | International Organization for  |
   |                                 | Standardization,                |
   |                                 | http://www.iso.ch/              |
   | ISO-IEC/JTC1                    | Joint Technical Committee of    |
   |                                 | the International Organization  |
   |                                 | for Standardization and         |
   |                                 | International Electrotechnical  |
   |                                 | Commission,                     |
   |                                 | http://www.jtc1.org/            |
   | ISOC                            | Internet Society,               |
   |                                 | http://www.isoc.org             |
   | ITU                             | International Telecommunication |
   |                                 | Union, http://www.itu.int       |
   | RFC                             | Request For Comments            |
   | STD                             | Standard (RFC)                  |
   | W3C                             | World Wide Web Consortium,      |
   |                                 | http://www.w3.org/              |
   | WG                              | Working Group                   |
   +---------------------------------+---------------------------------+

                  Table 4: Acronyms and Abbreviations





Harris & Hoffman         Expires April 19, 2005                [Page 42]


Internet-Draft              The Tao of IETF                 October 2004


Appendix B.  Changes and additions before this document is finished

   [[ This section is to be removed before publication as an RFC.  ]]

   Larger areas known to need changes or additions:

   o  The section on 'Patents in IETF Standards'

   o  Need new material on what WG participants should expect from WG
      chairs


   Smaller areas known to need changes or additions:

   o  Working group design teams

   o  Meaning of "updates" vs.  "obsoletes" in RFCs.

   o  IETF Rights in Contributions,
      draft-ietf-ipr-subm-rights-fix-00.txt now a BCP


Appendix C.  Changes since RFC 3160

   [[ This section is to be combined and summarized before publication
   as an RFC.  ]]

C.1  Changes in -00

   General changes:

   o  Everything was renumbered due to the new use of xml2rfc.  Many
      things were reformatted as well.

   o  Updated some of the references, changing their designations as
      BCPs and STDs.

   o  Fixed some links that had broken over time.


   New and changed content:

   o  Added the text to the intro about this document being intended to
      obsolete FYI 17.

   o  Removed names of individuals no longer associated with their
      previous roles.




Harris & Hoffman         Expires April 19, 2005                [Page 43]


Internet-Draft              The Tao of IETF                 October 2004


   o  Added note that not all IETF meetings have social events.

   o  Removed the discussion of agendas for previous meetings, because
      they are not kept around.

   o  Removed discussion of the User Services Area, since it has been
      closed.

   o  Added the paragraph about meeting at the IETF registration area.

   o  Changed "Only the Secretariat can send messages to the
      announcement list." to "Only the Secretariat can approve messages
      sent to the announcement list, although those messages can come
      from a variety of people."

   o  Added ietf-action@ietf.org to the useful email address list

   o  Changed the "Newcomer Training" section title and text to reflect
      the new name for the "Newcomer's Orientation"

   o  Added section ="EDU to the Rescue" about the EDU Team.

   o  Changed the first sentence to mention the EDU team in the "Working
      Group Chairs" section.

   o  Changed the title of the "Tao" subhead to Why "The Tao?" because
      "Tao" by itself looked peculiar in the Table of Contents.

   o  Added text at the beginning of "Patents in IETF Standards" to note
      that it'll be updated in -01.

   o  Changed the "Newcomer Training" section title and text to reflect
      the new name for the "Newcomer's Orientation".


C.2  Changes in -01

   o  There have been more than 60 meetings now.

   o  Changed "get a bite to eat" to "get a small bite to eat" at the
      reception.

   o  Using the registration desk for leaving messages for other
      attendees, and as the lost and found center.

   o  Updated the section on the terminal room to reflect current
      practice.




Harris & Hoffman         Expires April 19, 2005                [Page 44]


Internet-Draft              The Tao of IETF                 October 2004


   o  Removed mention of the print version of the proceedings.

   o  Added laptop hints in the "other general things" section.

   o  Updated the list of email addresses in A.2 to match Secretariat

   o  Added text about humming and Jabber in section 5.2

   o  Added text about I-D Tracker in section 8.3

   o  Added a new section, 3.3, about potential IETF changes

   o  Talked about mailman in addition to Majordomo.

   o  Added paragraph near the end of the IETF section affirming that
      the IETF does not run the Internet

   o  Added a paragraph about draft naming with -bis.

   o  Added lots of things to the "Getting Things Done in a Working
      Group" section.






























Harris & Hoffman         Expires April 19, 2005                [Page 45]


Internet-Draft              The Tao of IETF                 October 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Harris & Hoffman         Expires April 19, 2005                [Page 46]