doc: Add RFC documents

1 files changed, 2131 insertions, 0 deletions

diff --git a/doc/rfc/rfc3160.txt b/doc/rfc/rfc3160.txt
new file mode 100644
index 0000000..5145046
--- /dev/null
+++ b/doc/rfc/rfc3160.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Network Working Group                                          S. Harris
+Request for Comments: 3160                                 Merit Network
+FYI: 17                                                      August 2001
+Obsoletes: 1718
+Category: Informational
+
+
+    The Tao of IETF - A Novice's Guide to the Internet Engineering
+                               Task Force
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes the inner workings of IETF meetings and
+   Working Groups, discusses organizations related to the IETF, and
+   introduces the standards process.
+
+Table of Contents
+
+   Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .   3
+   1. What Is the IETF?  . . . . . . . . . . . . . . . . . . . . .   4
+      1.1 Humble Beginnings. . . . . . . . . . . . . . . . . . . .   5
+      1.2 The Hierarchy  . . . . . . . . . . . . . . . . . . . . .   5
+          1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . .   5
+          1.2.2 IESG . . . .  . . . . . . . . . . . . . .  . . . .   6
+          1.2.3 IAB. . . . . . . . . . . . . . . . . . . . . . . .   7
+          1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . .   8
+          1.2.5 RFC Editor . . . . . . . . . . . . . . . . . . . .   8
+          1.2.6 IETF Secretariat . . . . . . . . . . . . . . . . .   9
+      1.3  IETF Mailing Lists. . . . . . . . . . . . . . . . . . .   9
+   2.  IETF Meetings   . . . . . . . . . . . . . . . . . . . . . .  10
+       2.1 Registration  . . . . . . . . . . . . . . . . . . . . .  11
+       2.2 Newcomers' Orientation. . . . . . . . . . . . . . . . .  12
+       2.3 Dress Code. . . . . . . . . . . . . . . . . . . . . . .  12
+       2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . .  13
+       2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . .  13
+       2.6 Meals and Other Delights. . . . . . . . . . . . . . . .  14
+       2.7 Social Event. . . . . . . . . . . . . . . . . . . . . .  14
+
+
+
+Harris                       Informational                      [Page 1]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+       2.8 Agenda. . . . . . . . . . . . . . . . . . . . . . . . .  14
+       2.9 Where Do I Fit In?. . . . . . . . . . . . . . . . . . .  15
+           2.9.1  IS Managers. . . . . . . . . . . . . . . . . . .  15
+           2.9.2  Network Operators and ISPs . . . . . . . . . . .  15
+           2.9.3  Networking Hardware and Software Vendors . . . .  15
+           2.9.4  Academics  . . . . . . . . . . . . . . . . . . .  16
+           2.9.5  Computer Trade Press . . . . . . . . . . . . . .  16
+       2.10 Proceedings. . . . . . . . . . . . . . . . . . . . . .  16
+       2.11 Other General Things . . . . . . . . . . . . . . . . .  17
+   3.  Working Groups. . . . . . . . . . . . . . . . . . . . . . .  18
+       3.1 Working Group Chairs  . . . . . . . . . . . . . . . . . .18
+       3.2 Getting Things Done in a Working Group. . . . . . . . .  19
+       3.3 Preparing for Working Group Meetings    . . . . . . . .  19
+       3.4 Working Group Mailing Lists   . . . . . . . . . . . . .  20
+       3.5 Interim Working Group Meetings  . . . . . . . . . . . .  21
+   4.  BOFs. . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
+   5.  New to the IETF?  STOP HERE! (Temporarily). . . . . . . . .  22
+   6.  RFCs and Internet Drafts  . . . . . . . . . . . . . . . . .  22
+       6.1 Getting a Standard Published  . . . . . . . . . . . . .  22
+       6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . .  24
+       6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . .  24
+           6.3.1 Recommended Reading for Writers . . . . . . . . .  25
+           6.3.2 Filenames and Other Matters . . . . . . . . . . .  26
+       6.4 Standards-Track RFCs  . . . . . . . . . . . . . . . . .  26
+           6.4.1 Telling It Like It Is -- Using MUST and
+                 SHOULD and MAY. . . . . . . . . . . . . . . . . .  27
+           6.4.2 Normative References in Standards . . . . . . . .  28
+           6.4.3 IANA Considerations . . . . . . . . . . . . . . .  29
+           6.4.4 Security Considerations . . . . . . . . . . . . .  29
+           6.4.5 Patents in IETF Standards . . . . . . . . . . . .  30
+       6.5 Informational and Experimental RFCs . . . . . . . . . .  31
+   7. How to Contribute to the IETF -- What You Can Do . . . . . .  31
+       7.1  What Your Company Can Do . . . . . . . . . . . . . . .  32
+   8. IETF and the Outside World . . . . . . . . . . . . . . . . .  33
+       8.1 IETF and Other Standards Groups . . . . . . . . . . . .  33
+       8.2 Press Coverage of the IETF. . . . . . . . . . . . . . .  33
+   9. References . . . . . . . . . . . . . . . . . . . . . . . . .  35
+       9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . .  35
+       9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . .  35
+       9.3 Useful Documents and Files. . . . . . . . . . . . . . .  35
+       9.4 Acronyms and Abbreviations Used in the Tao  . . . . . .  36
+       9.5 Documents Cited in the Tao  . . . . . . . . . . . . . .  36
+   Security Considerations . . . . . . . . . . . . . . . . . . . .  37
+   Editor's Address  . . . . . . . . . . . . . . . . . . . . . . .  37
+   Full Copyright Statement  . . . . . . . . . . . . . . . . . . .  38
+
+
+
+
+
+
+Harris                       Informational                      [Page 2]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+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 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 6 for more information.)
+
+   The acronyms and abbreviations used in this document are usually
+   expanded in place, and are explained fully in Section 9.
+
+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                       Informational                      [Page 3]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+1. 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:
+
+   -  Identifying, and proposing solutions to, pressing operational and
+      technical problems in the Internet;
+
+   -  Specifying the development or usage of protocols and the near-term
+      architecture to solve such technical problems for the Internet;
+
+   -  Making recommendations to the Internet Engineering Steering Group
+      (IESG) regarding the standardization of protocols and protocol
+      usage in the Internet;
+
+   -  Facilitating technology transfer from the Internet Research Task
+      Force (IRTF) to the wider Internet community; and
+
+   -  Providing a forum for the exchange of information within the
+      Internet community between vendors, users, researchers, agency
+      contractors, and network managers.
+
+   The IETF meeting is not a conference, although there are technical
+   presentations.  The IETF is not a traditional standards organization,
+   although many specifications are produced that become standards.  The
+   IETF is made up of volunteers, 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 1.3).  This is where the best information about current IETF
+   activities and focus can be found.
+
+   Of course, no organization can be as successful as the IETF is
+   without having some sort of structure.  In the IETF's case, that
+   structure is provided by other organizations, as described in BCP 11,
+   "The Organizations Involved in the IETF Standards Process."  If you
+   participate in the IETF and only read one BCP, this is the one you
+   should read.
+
+
+
+
+
+Harris                       Informational                      [Page 4]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+1.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.
+
+1.2 The Hierarchy
+
+1.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
+   wants to say something to the press.  The ISOC is one of the major
+   unsung (and under-funded) heroes of the Internet.
+
+
+
+
+
+
+
+Harris                       Informational                      [Page 5]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+1.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, "IAB and IESG Selection, Confirmation,
+   and Recall Process:  Operation of the Nominating and Recall
+   Committees."
+
+   The current areas and abbreviations are:
+
+   -  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       Operational aspects, network monitoring,
+      Management (OPS)     and configuration
+   -  Routing (RTG)        Getting packets to their destinations
+   -  Security (SEC)       Authentication and privacy
+   -  Transport (TSV)      Special services for special packets
+   -  User Services (USV)  Support for end users and user support
+                           organizations
+
+   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
+   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
+
+
+
+Harris                       Informational                      [Page 6]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+1.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.
+   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.
+
+
+
+
+
+Harris                       Informational                      [Page 7]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   The IAB also:
+
+   -  Approves Nomcom's IESG nominations
+   -  Acts as the appeals board for appeals against IESG actions
+   -  Appoints and oversees the RFC Editor
+   -  Approves the appointment of the IANA
+   -  Acts as an advisory body to the ISOC
+   -  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.
+
+1.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
+   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.
+
+1.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.
+
+
+
+Harris                       Informational                      [Page 8]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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 rfc-ed@rfc-editor.org.
+
+1.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.
+
+1.3  IETF Mailing Lists
+
+   Anyone who plans to attend an IETF meeting should join the IETF
+   announcement mailing list, "ietf-announce@ietf.org".  This is where
+   all of the meeting information, Internet Draft and RFC announcements,
+   and IESG Protocol Actions and Last Calls are posted.  People who
+   would like to "get technical" may also join the IETF discussion list,
+   "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).
+
+   Subscriptions to these and other IETF mailing lists are handled by a
+   program called Majordomo.  Majordomo tends to be somewhat finicky
+   about the format of subscription messages, and interacts poorly with
+   email programs that make all email messages into HTML files.
+   Majordomo 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:
+
+      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:
+
+      ietf-request@ietf.org
+
+
+
+
+
+
+Harris                       Informational                      [Page 9]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   and enter the word 'subscribe' as explained above.  If you decide to
+   withdraw from either list, use the word 'unsubscribe.' Your messages
+   to Majordomo 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,
+   it is not a place for companies or individuals to solicit or
+   advertise, as noted in "IETF Discussion List Charter," RFC 3005.  It
+   is a good idea to read the whole RFC (it's short!) before posting to
+   the IETF discussion list.
+
+   Only the Secretariat can send messages to the announcement list.
+
+   Even though the IETF mailing lists "represent" the IETF membership at
+   large, it is important to note that attending an IETF meeting does
+   not mean you'll be automatically added to either mailing list.
+
+2. 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.
+
+
+
+Harris                       Informational                     [Page 10]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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 over 50 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.
+
+2.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 (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 bite to eat and socialize with other early
+   arrivals.
+
+
+
+
+
+
+Harris                       Informational                     [Page 11]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+2.2 Newcomers' Orientation
+
+   Newcomers are encouraged to attend the Newcomers' Orientation, which
+   is especially designed for first-time attendees.  The orientation is
+   organized and conducted by the IETF Secretariat, and is intended to
+   provide useful introductory information.  The orientation 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!
+
+2.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
+
+
+
+
+
+Harris                       Informational                     [Page 12]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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!).
+
+2.4 Seeing Spots Before Your Eyes
+
+   Some of the people at the IETF will have a little colored dot on
+   their name tag.  A few people have more than one.  These dots
+   identify people who are silly enough to volunteer to do a lot of
+   extra work.  The colors have the following meanings:
+
+      blue    -  Working Group/BOF chair
+      green   -  Host group
+      red     -  IAB member
+      yellow  -  IESG member
+      orange  -  Nominating Committee member
+
+   (Members of the press wear orange-tinted badges.)
+
+   Local hosts are the people who can answer questions about the
+   terminal room, restaurants, and points of interest in the area.
+
+   It is important that newcomers to the IETF not be afraid to strike up
+   conversations with people who wear these dots.  If the IAB and IESG
+   members and Working Group and BOF chairs didn't want to talk to
+   anybody, they wouldn't be wearing the dots in the first place.
+
+2.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.  The terminal room provides workstations, one or two
+   printers, and ports for laptops.
+
+
+
+
+
+
+
+
+Harris                       Informational                     [Page 13]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+2.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.
+
+2.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 the Boston IETF, for
+   example, the social was dinner at the Computer Museum.  Other times,
+   the social might be a dinner cruise or a trip to an art gallery.
+
+   Newcomers to the IETF are encouraged to attend the social event.
+   Everyone is encouraged to wear their name tags and leave their
+   laptops behind.  The social event is designed to give people a chance
+   to meet on a social, rather than technical, level.
+
+2.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 agenda for the 50th
+   IETF, for example, is at http://www.ietf.org/meetings/agenda_50.html.
+   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                       Informational                     [Page 14]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+2.9  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.
+
+2.9.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.
+
+2.9.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
+   switching, the more likely it is that you will be able to learn and
+   contribute at an IETF meeting.
+
+2.9.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
+
+
+
+Harris                       Informational                     [Page 15]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+2.9.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.
+
+2.9.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 8.2.
+
+2.10  Proceedings
+
+   IETF proceedings are compiled in the two months following each
+   meeting, and are available on the web, on CD, and in print.  Be sure
+   to look through a copy -- the proceedings are filled with information
+   about IETF that you're not likely to find anywhere else.  For
+   example, you'll find snapshots of most WG charters at the time of the
+   meeting, giving you a better understanding of the evolution of any
+   given effort.
+
+   The proceedings usually start with an informative (and highly
+   entertaining) message from Steve Coya, the Executive Director of the
+   IETF.  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.
+
+
+
+Harris                       Informational                     [Page 16]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+2.11  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.
+
+   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.
+
+
+
+
+
+
+
+Harris                       Informational                     [Page 17]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+3.0 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, "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.
+
+3.1 Working Group Chairs
+
+   The role of the WG chairs is described in both BCP 11 and BCP 25.
+   Basically, their job is 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
+
+
+
+
+Harris                       Informational                     [Page 18]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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/wgchair/index.htm.
+
+3.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
+   to Working Group.  The lack of voting has caused some very long
+   delays for some proposals, but most IETF participants who have
+   witnessed rough consensus after acrimonious debates feel that the
+   delays often result in better protocols.  (And, if you think about
+   it, how could you have "voting" in a group that anyone can join, and
+   when it's impossible to count the participants?)
+
+3.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.
+
+
+
+Harris                       Informational                     [Page 19]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   It's up to the WG chair to set the meeting agenda, usually a few
+   weeks in advance.  If you want something discussed at the meeting, be
+   sure to let the chair know about it.  The agendas for all the WG
+   meetings are available in advance (see
+   http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the
+   meeting number), but many WG chairs are lax (if not totally
+   negligent) about turning them in.
+
+   The Secretariat only schedules WG meetings a few weeks in advance,
+   and the schedule often changes as little as a week before the first
+   day.  If you are only coming for one WG meeting, you may have a hard
+   time booking your flight with such little notice, particularly if the
+   Working Group's meeting changes schedule.  Be sure to keep track of
+   the current agenda so you can schedule flights and hotels.  But, when
+   it comes down to it, you probably shouldn't be coming for just one WG
+   meeting.  It's likely that your knowledge could be valuable in a few
+   WGs, assuming that you've read the drafts and RFCs for those groups.
+
+   If you'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.
+
+3.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.
+
+
+
+
+
+
+Harris                       Informational                     [Page 20]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   Most IETF discussion lists use Majordomo and have a "-request"
+   address which handles the administrative details of joining and
+   leaving the list.  (See Section 1.3 for more information on
+   Majordomo.)  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!).
+
+3.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 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 minutes@ietf.org, and the group needs to take
+   attendance.
+
+4. 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                       Informational                     [Page 21]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+5.  ** 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.
+
+6. 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.
+
+6.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                       Informational                     [Page 22]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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, "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:
+
+      -  Proposed standards
+      -  Draft standards
+      -  Internet standards (sometimes called "full standards")
+      -  Experimental protocols
+      -  Informational documents
+      -  Historic standards
+
+   Only the first three (proposed, draft, and full) are standards within
+   the IETF.  A good summary of this can be found in the aptly titled
+   RFC 1796, "Not All RFCs are Standards."
+
+   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.  Frequently, FYIs are created by groups within the
+   IETF User Services Area.  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.
+
+
+
+
+
+Harris                       Informational                     [Page 23]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+6.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.
+
+6.3 Internet Drafts
+
+   First things first.  Every document that ends up in the RFC
+   repository starts life as an Internet Draft.  Internet Drafts are
+   tentative documents -- they're meant for readers to comment on, so
+   authors can mull over those comments and decide which ones to
+   incorporate in the draft.  In order to remind folks of their
+   tentativeness, Internet Drafts are automatically removed from the
+   online directories after six months.  They are most definitely not
+   standards or even specifications.  As BCP 9 says:
+
+      An Internet Draft is NOT a means of "publishing" a specification;
+      specifications are published through the RFC mechanism ...
+      Internet Drafts have no formal status, and are subject to change
+      or removal at any time.  Under no circumstances should an Internet
+      Draft be referenced by any paper, report, or Request-for-Proposal,
+      nor should a vendor claim compliance with an Internet Draft.
+
+
+
+Harris                       Informational                     [Page 24]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   You can always tell a person who doesn't understand the IETF (or is
+   intentionally trying to fool people) when they brag about having
+   published an Internet Draft; it takes no significant effort.
+
+   An I-D should have approximately the same format as an RFC.  Contrary
+   to many people's beliefs, an I-D does not need to look exactly like
+   an RFC, but if you can use the same formatting procedures used by the
+   RFC Editor when you create your I-Ds, it will simplify the RFC
+   Editor's work when your draft is published as an RFC.  RFC 2223,
+   "Instructions to RFC Authors," describes the nroff formatting used by
+   the RFC Editor.
+
+   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.
+
+6.3.1 Recommended Reading for Writers
+
+   Before you create the first draft of your Internet Draft, you should
+   read four documents:
+
+      - More important than just explaining formatting, RFC 2223 also
+        explains what needs to be in an Internet Draft before it can
+        become an RFC.  This document describes all the sections and
+        notices that will need to be in your document, and it's good to
+        have them there from the beginning so that readers aren't
+        surprised when you put them in later versions.
+
+      - BCP 22, "Guide for Internet Standards Writers," 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.
+
+      - 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.
+
+      - 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.
+
+
+
+
+Harris                       Informational                     [Page 25]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+6.3.2 Filenames and Other Matters
+
+   When you're ready to turn in your Internet Draft, send it to the
+   Internet Drafts editor at 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.
+
+   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.
+
+6.4 Standards-Track RFCs
+
+   The procedure for creating and advancing a standard is described in
+   BCP 9.  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
+
+
+
+Harris                       Informational                     [Page 26]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+   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.
+
+6.4.1 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.
+
+
+
+
+Harris                       Informational                     [Page 27]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+   RFC 1123, "Requirements for Internet Hosts -- Application and
+   Support," written way back in 1989, had a short list of words that
+   had appeared to be useful, namely "must", "should", and "may".  These
+   definitions were updated and further refined in BCP 14, "Key words
+   for use in RFCs to Indicate Requirement Levels," which is widely
+   referenced in current Internet standards.  BCP 14 also specifically
+   defines "must not" and "should not", and lists a few synonyms for the
+   words defined.
+
+   In a standard, in order to make it clear that you'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
+   "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.
+
+6.4.2 Normative References in Standards
+
+   One aspect of writing IETF standards that trips up many novices (and
+   quite a few long-time IETF folk) is the rule about how to make
+   "normative references" to non-IETF documents or to other RFCs in a
+   standard.  A normative reference is a reference to a document that
+   must be followed in order to implement the standard.  A non-normative
+   reference is one that is helpful to an implementor but is not needed.
+   As 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
+
+
+
+Harris                       Informational                     [Page 28]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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
+   the WG chair or appropriate Area Director if a particular external
+   standard can be used in an IETF standard.
+
+6.4.3 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 1.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, "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.
+
+6.4.4 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
+
+
+
+Harris                       Informational                     [Page 29]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+6.4.5 Patents in IETF Standards
+
+   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
+   something that is so valuable that there isn't a non-patented
+   equivalent.  Sometimes, the patent holder is generous and promises to
+   give all implementors of a standard a royalty-free license to the
+   patent, thereby making it almost as easy to implement as it would
+   have been if no patent existed.
+
+   The IETF's methods for dealing with patents in standards are a
+   subject of much debate.  You can read about the official rules in BCP
+   9, but you should assume that the application of those rules is
+   flexible and depends on the type of patent, the patent holder, and
+   the availability of alternate technologies that are not encumbered by
+   patents.
+
+   Patent holders who freely allow their patents to be used by people
+   implementing IETF standards often get a great deal of good will from
+   the folks in the IETF.  Such generosity is more common than you might
+   think.  For example, RFC 1822 is a license from IBM for one of its
+   security patents, and the security community has responded very
+   favorably to IBM for this (whereas a number of other companies have
+   made themselves pariahs for their intractability on their security
+   patents).
+
+   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
+   (ietf-secretariat@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
+
+
+
+Harris                       Informational                     [Page 30]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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 provides
+   specific text that should be added to RFCs where the author knows of
+   IPR issues.
+
+6.5 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
+   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.
+
+7. How to Contribute to the IETF -- 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.
+
+
+
+
+
+Harris                       Informational                     [Page 31]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+7.1  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.
+
+
+
+
+
+
+Harris                       Informational                     [Page 32]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+8. IETF and the Outside World
+
+8.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-
+   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.
+
+8.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.
+
+
+
+
+
+
+
+Harris                       Informational                     [Page 33]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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
+   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
+
+
+
+Harris                       Informational                     [Page 34]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   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.
+
+9. References
+
+9.1 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.
+
+9.2 Useful E-mail Addresses
+
+   agenda@ietf.org              Requests for agenda slots at IETF
+                                     meetings
+   ietf-info@ietf.org           General questions about the IETF
+   ietf-registrar@ietf.org      Questions about registration, meeting
+                                     locations, and fees
+   ietf-request@ietf.org        Requests to join/leave IETF lists
+   ietf-secretariat@ietf.org    Questions for the Secretariat
+   ietf-web@ietf.org            Web questions/comments
+   internet-drafts@ietf.org     Internet Draft submissions and queries
+   minutes@ietf.org             Where to send Working Group minutes
+   proceedings@ietf.org         IETF Proceedings Coordinator
+   iana@iana.org                Internet Assigned Numbers Authority
+   rfc-ed@rfc-editor.org        RFC Editor
+
+9.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.
+
+
+
+
+
+Harris                       Informational                     [Page 35]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+9.4 Acronyms and Abbreviations Used in the Tao
+
+   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/conferences/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
+
+9.5 Documents Cited in the Tao
+
+   BCP 9     "The Internet Standards Process"
+   BCP 10    "IAB and IESG Selection, Confirmation, and Recall Process:
+              Operation of the Nominating and Recall Committees"
+   BCP 11    "The Organizations Involved in the IETF Standards Process"
+   BCP 14    "Key words for use in RFCs to Indicate Requirement Levels"
+   BCP 22    "Guide for Internet Standards Writers"
+   BCP 25    "IETF Working Group Guidelines and Procedures"
+   BCP 26    "Guidelines for Writing an IANA Considerations Section
+              in RFCs"
+   RFC 1123  "Requirements for Internet Hosts -- Application and
+              Support"
+   RFC 1796  "Not All RFCs are Standards"
+   RFC 2223  "Instructions to RFC Authors"
+
+
+
+
+
+Harris                       Informational                     [Page 36]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+   "Considerations for Internet Drafts,"
+      http://www.ietf.org/ID-nits.html
+
+   "Guidelines to Authors of Internet-Drafts,"
+      ftp://ftp.ietf.org/ietf/1id-guidelines.txt
+
+Security Considerations
+
+   Section 6.4.5 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.
+
+Editor's Address
+
+   Susan Harris
+   Merit Network, Inc.
+   4251 Plymouth Road, Suite 2000
+   Ann Arbor, MI  48105
+
+   EMail: srh@merit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harris                       Informational                     [Page 37]
+
+RFC 3160                    The Tao of IETF                  August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harris                       Informational                     [Page 38]
+