From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc4677.txt | 2803 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2803 insertions(+)
 create mode 100644 doc/rfc/rfc4677.txt

(limited to 'doc/rfc/rfc4677.txt')

diff --git a/doc/rfc/rfc4677.txt b/doc/rfc/rfc4677.txt
new file mode 100644
index 0000000..3e53e90
--- /dev/null
+++ b/doc/rfc/rfc4677.txt
@@ -0,0 +1,2803 @@
+
+
+
+
+
+
+Network Working Group                                         P. Hoffman
+Request for Comments: 4677                                VPN Consortium
+FYI: 17                                                        S. Harris
+Obsoletes: 3160                                   University of Michigan
+Category: Informational                                   September 2006
+
+
+                 The Tao of IETF: A Novice's Guide to
+                  the Internet Engineering Task Force
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the inner workings of IETF meetings and
+   Working Groups, discusses organizations related to the IETF, and
+   introduces the standards process.  It is not a formal IETF process
+   document but instead an informational overview.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                      [Page 1]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Acknowledgements ................................................5
+   3. What Is the IETF? ...............................................5
+      3.1. Humble Beginnings ..........................................6
+      3.2. The Hierarchy ..............................................7
+           3.2.1. ISOC (Internet Society) .............................7
+           3.2.2. IESG (Internet Engineering Steering Group) ..........8
+           3.2.3. IAB (Internet Architecture Board) ..................10
+           3.2.4. IANA (Internet Assigned Numbers Authority) .........11
+           3.2.5. RFC Editor .........................................11
+           3.2.6. IETF Secretariat ...................................12
+      3.3. IETF Mailing Lists ........................................12
+   4. IETF Meetings ..................................................13
+      4.1. Registration ..............................................14
+      4.2. Take the Plunge and Stay All Week! ........................15
+      4.3. Newcomer Training .........................................16
+      4.4. Dress Code ................................................16
+      4.5. Seeing Spots Before Your Eyes .............................16
+      4.6. Terminal Room .............................................17
+      4.7. Meals and Other Delights ..................................17
+      4.8. Social Event ..............................................18
+      4.9. Agenda ....................................................18
+      4.10. EDU to the Rescue ........................................19
+      4.11. Where Do I Fit In? .......................................19
+           4.11.1. IS Managers .......................................19
+           4.11.2. Network Operators and ISPs ........................19
+           4.11.3. Networking Hardware and Software Vendors ..........20
+           4.11.4. Academics .........................................20
+           4.11.5. Computer Trade Press ..............................20
+      4.12. Proceedings ..............................................21
+      4.13. Other General Things .....................................21
+   5. Working Groups .................................................22
+      5.1. Working Group Chairs ......................................23
+      5.2. Getting Things Done in a Working Group ....................24
+      5.3. Preparing for Working Group Meetings ......................25
+      5.4. Working Group Mailing Lists ...............................26
+      5.5. Interim Working Group Meetings ............................27
+   6. BOFs ...........................................................27
+   7. New to the IETF and Coming to a Meeting? STOP HERE!
+      (Temporarily) ..................................................28
+   8. RFCs and Internet Drafts .......................................29
+      8.1. Getting an RFC Published ..................................29
+      8.2. Letting Go Gracefully .....................................30
+      8.3. Internet Drafts ...........................................31
+           8.3.1. Recommended Reading for Writers ....................32
+           8.3.2. Filenames and Other Matters ........................33
+
+
+
+Hoffman & Harris             Informational                      [Page 2]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+      8.4. Standards-Track RFCs ......................................34
+           8.4.1. Telling It Like It Is -- Using MUST and SHOULD
+                  and MAY ............................................35
+           8.4.2. Normative References in Standards ..................36
+           8.4.3. IANA Considerations ................................37
+           8.4.4. Security Considerations ............................37
+           8.4.5. Patents in IETF Standards ..........................37
+      8.5. Informational and Experimental RFCs .......................38
+   9. How to Contribute to the IETF ..................................39
+      9.1. What You Can Do ...........................................39
+      9.2. What Your Company Can Do ..................................40
+   10. IETF and the Outside World ....................................40
+      10.1. IETF and Other Standards Groups ..........................40
+      10.2. Press Coverage of the IETF ...............................41
+   11. Security Considerations .......................................42
+   Appendix A. Related Information ...................................43
+      A.1. Why "the Tao"? ............................................43
+      A.2. Useful Email Addresses ....................................43
+      A.3. Useful Documents and Files ................................44
+      A.4. Acronyms and Abbreviations Used in the Tao ................44
+   Appendix B. IETF Guiding Principles ...............................45
+      B.1. General ...................................................45
+      B.2. Management and Leadership .................................45
+      B.3. Process ...................................................46
+      B.4. Working Groups ............................................46
+      B.5. Documents .................................................47
+   Informative References ............................................48
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                      [Page 3]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+1.  Introduction
+
+   Since its early years, attendance at Internet Engineering Task Force
+   (IETF) face-to-face meetings has grown phenomenally.  Many of the
+   attendees are new to the IETF at each meeting, and many of those go
+   on to become regular attendees.  When the meetings were smaller, it
+   was relatively easy for a newcomer to get into the swing of things.
+   Today, however, a newcomer meets many more new people, some
+   previously known only as the authors of documents or thought-
+   provoking email messages.
+
+   This document describes many aspects of the IETF, with the goal of
+   explaining to newcomers how the IETF works.  This will give them a
+   warm, fuzzy feeling and enable them to make the meeting and the
+   Working Group discussions more productive for everyone.
+
+   Of course, it's true that many IETF participants don't go to the
+   face-to-face meetings at all.  Instead, they're active on the mailing
+   list of various IETF Working Groups.  Since the inner workings of
+   Working Groups can be hard for newcomers to understand, this document
+   provides the mundane bits of information that newcomers will need in
+   order to become active participants.
+
+   The IETF is always in a state of change.  Although the principles in
+   this document are expected to remain largely the same over time,
+   practical details may well have changed by the time you read it; for
+   example, a web-based tool may have replaced an email address for
+   requesting some sort of action.
+
+   Many types of IETF documentation are mentioned in the Tao, from BCPs
+   to RFCs and FYIs and STDs.  BCPs make recommendations for Best
+   Current Practices in the Internet; RFCs are the IETF's main technical
+   documentation series, politely known as "Requests for Comments"; FYIs
+   provide topical and technical overviews that are introductory or
+   appeal to a broad audience; and STDs are RFCs identified as
+   "standards".  See Section 8 for more information.
+
+   The acronyms and abbreviations used in this document are usually
+   expanded in place and are explained fully in Appendix A.
+
+   This document is intended to obsolete FYI 17, RFC 3160.  See Section
+   3.2.5 for information on what it means for one RFC to obsolete
+   another.
+
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                      [Page 4]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+2.  Acknowledgements
+
+   The original version of this document, published in 1994, was written
+   by Gary Malkin.  His knowledge of the IETF, insights, and unmatched
+   writing style set the standard for this later revision, and his
+   contributions to the current document are also much appreciated.
+   Paul Hoffman wrote significant portions of this revision and provided
+   encouragement, expertise, and much-needed guidance.  Other
+   contributors include Brian Carpenter, Scott Bradner, Michael Patton,
+   Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault,
+   the IETF Secretariat, members of the User Services Working Group, and
+   members of the PESCI design team.
+
+3.  What Is the IETF?
+
+   The Internet Engineering Task Force is a loosely self-organized group
+   of people who contribute to the engineering and evolution of Internet
+   technologies.  It is the principal body engaged in the development of
+   new Internet standard specifications.  The IETF is unusual in that it
+   exists as a collection of happenings, but is not a corporation and
+   has no board of directors, no members, and no dues; see [BCP95], "A
+   Mission Statement for the IETF", for more detail.
+
+   Its mission includes the following:
+
+   o  Identifying, and proposing solutions to, pressing operational and
+      technical problems in the Internet
+
+   o  Specifying the development or usage of protocols and the near-term
+      architecture to solve such technical problems for the Internet
+
+   o  Making recommendations to the Internet Engineering Steering Group
+      (IESG) regarding the standardization of protocols and protocol
+      usage in the Internet
+
+   o  Facilitating technology transfer from the Internet Research Task
+      Force (IRTF) to the wider Internet community
+
+   o  Providing a forum for the exchange of information within the
+      Internet community between vendors, users, researchers, agency
+      contractors, and network managers
+
+   The IETF meeting is not a conference, although there are technical
+   presentations.  The IETF is not a traditional standards organization,
+   although many specifications are produced that become standards.  The
+   IETF is made up of volunteers, many of whom meet three times a year
+   to fulfill the IETF mission.
+
+
+
+
+Hoffman & Harris             Informational                      [Page 5]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   There is no membership in the IETF.  Anyone may register for and
+   attend any meeting.  The closest thing there is to being an IETF
+   member is being on the IETF or Working Group mailing lists (see
+   Section 3.3).  This is where the best information about current IETF
+   activities and focus can be found.
+
+   Of course, no organization can be as successful as the IETF is
+   without having some sort of structure.  In the IETF's case, that
+   structure is provided by other organizations, as described in
+   [BCP11], "The Organizations Involved in the IETF Standards Process".
+   If you participate in the IETF and read only one BCP, this is the one
+   you should read.
+
+   In many ways, the IETF runs on the beliefs of its members.  One of
+   the "founding beliefs" is embodied in an early quote about the IETF
+   from David Clark: "We reject kings, presidents and voting.  We
+   believe in rough consensus and running code".  Another early quote
+   that has become a commonly-held belief in the IETF comes from Jon
+   Postel: "Be conservative in what you send and liberal in what you
+   accept".
+
+   The IETF is really about its members.  Because of the unrestrictive
+   membership policies, IETF members come from all over the world and
+   from many different parts of the Internet industry.  See Section 4.11
+   for information about the ways that many people fit into the IETF.
+
+   One more thing that is important for newcomers: the IETF in no way
+   "runs the Internet", despite what some people mistakenly might say.
+   The IETF makes standards that are often adopted by Internet users,
+   but it does not control, or even patrol, the Internet.  If your
+   interest in the IETF is because you want to be part of the overseers,
+   you may be badly disappointed by the IETF.
+
+3.1.  Humble Beginnings
+
+   The first IETF meeting was held in January 1986 at Linkabit in San
+   Diego, with 21 attendees.  The 4th IETF, held at SRI in Menlo Park in
+   October 1986, was the first that non-government vendors attended.
+   The concept of Working Groups was introduced at the 5th IETF meeting
+   at the NASA Ames Research Center in California in February 1987.  The
+   7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the
+   first meeting with more than 100 attendees.
+
+
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                      [Page 6]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   The 14th IETF meeting was held at Stanford University in July 1989.
+   It marked a major change in the structure of the IETF universe.  The
+   IAB (then Internet Activities Board, now Internet Architecture
+   Board), which until that time oversaw many "task forces", changed its
+   structure to leave only two: the IETF and the IRTF.  The IRTF is
+   tasked to consider long-term research problems in the Internet.  The
+   IETF also changed at that time.
+
+   After the Internet Society (ISOC) was formed in January 1992, the IAB
+   proposed to ISOC that the IAB's activities should take place under
+   the auspices of the Internet Society.  During INET92 in Kobe, Japan,
+   the ISOC Trustees approved a new charter for the IAB to reflect the
+   proposed relationship.
+
+   The IETF met in Amsterdam, The Netherlands, in July 1993.  This was
+   the first IETF meeting held in Europe, and the US/non-US attendee
+   split was nearly 50/50.  About one in three IETF meetings are now
+   held in Europe or Asia, and the number of non-US attendees continues
+   to be high -- about 50%, even at meetings held in the United States.
+
+3.2.  The Hierarchy
+
+3.2.1.  ISOC (Internet Society)
+
+   The Internet Society is an international, non-profit, membership
+   organization that fosters the expansion of the Internet.  One of the
+   ways that ISOC does this is through financial and legal support of
+   the other "I" groups described here, particularly the IETF.  ISOC
+   provides insurance coverage for many of the people in the IETF
+   process and acts as a public relations channel for the times that one
+   of the "I" groups wants to say something to the press.  The ISOC is
+   one of the major unsung (and under-supported) heroes of the Internet.
+
+   Starting in spring 2005, the ISOC also became home base for the
+   IETF's directly employed administrative staff.  This is described in
+   more detail in [BCP101], "Structure of the IETF Administrative
+   Support Activity (IASA)".  The staff initially includes only an
+   Administrative Director (IAD) who works full-time overseeing IETF
+   meeting planning, operational aspects of support services (the
+   secretariat, IANA (the Internet Assigned Numbers Authority), and the
+   RFC Editor, which are described later in this section), and the
+   budget.  He or she (currently it's a he) leads the IETF
+   Administrative Support Activity (IASA), which takes care of tasks
+   such as collecting meeting fees and paying invoices, and also
+   supports the tools for the work of IETF working groups, the IESG, the
+   IAB, and the IRTF (more about these later in this section).
+
+
+
+
+
+Hoffman & Harris             Informational                      [Page 7]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   As well as staff, the IASA comprises volunteers and ex officio
+   members from the ISOC and IETF leadership.  The IASA and the IAD are
+   directed by the IETF Administrative Oversight Committee (IAOC), which
+   is selected by the IETF community.  Here's how all this looks:
+
+                          Internet Society
+                                 |
+                                IAOC
+                                 |
+                                IASA
+                                 |
+                                IAD
+
+   Neither the IAD nor the IAOC have any influence over IETF standards
+   development, which we turn to now.
+
+3.2.2.  IESG (Internet Engineering Steering Group)
+
+   The IESG is responsible for technical management of IETF activities
+   and the Internet standards process.  It administers the process
+   according to the rules and procedures that have been ratified by the
+   ISOC Trustees.  However, the IESG doesn't do much direct leadership,
+   such as the kind you will find in many other standards organizations.
+   As its name suggests, its role is to set directions rather than to
+   give orders.  The IESG ratifies or corrects the output from the
+   IETF's Working Groups (WGs), gets WGs started and finished, and makes
+   sure that non-WG drafts that are about to become RFCs are correct.
+
+   The IESG consists of the Area Directors (ADs), who are selected by
+   the Nominations Committee (which is usually called "the NomCom") and
+   are appointed for two years.  The process for choosing the members of
+   the IESG is detailed in [BCP10], "IAB and IESG Selection,
+   Confirmation, and Recall Process: Operation of the Nominating and
+   Recall Committees".
+
+   The current areas and abbreviations are shown below.
+
+   Area                    Description
+   -----------------------------------------------------------------
+   Applications (APP)      Protocols seen by user programs, such as
+                           email and the web
+
+   General (GEN)           Catch-all for WGs that don't fit in other
+                           areas (which is very few)
+
+   Internet (INT)          Different ways of moving IP packets and
+                           DNS information
+
+
+
+
+Hoffman & Harris             Informational                      [Page 8]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   Operations and          Operational aspects, network monitoring,
+   Management (OPS)        and configuration
+
+   Real-time               Delay-sensitive interpersonal
+   Applications and        communications
+   Infrastructure (RAI)
+
+   Routing (RTG)           Getting packets to their destinations
+
+   Security (SEC)          Authentication and privacy
+
+   Transport (TSV)         Special services for special packets
+
+   Because the IESG has a great deal of influence on whether Internet
+   Drafts become RFCs, many people look at the ADs as somewhat godlike
+   creatures.  IETF participants sometimes reverently ask Area Directors
+   for their opinion on a particular subject.  However, most ADs are
+   nearly indistinguishable from mere mortals and rarely speak from
+   mountaintops.  In fact, when asked for specific technical comments,
+   the ADs may often defer to members at large whom they feel have more
+   knowledge than they do in that area.
+
+   The ADs for a particular area are expected to know more about the
+   combined work of the WGs in that area than anyone else.  On the other
+   hand, the entire IESG reviews each Internet Draft that is proposed to
+   become an RFC.  Any AD may record a "DISCUSS" ballot position against
+   a draft if he or she has serious concerns.  If these concerns cannot
+   be resolved by discussion, an override procedure is defined such that
+   at least two IESG members must express concerns before a draft can be
+   blocked from moving forward.  These procedures help ensure that an
+   AD's "pet project" doesn't make it onto the standards track if it
+   will have a negative effect on the rest of the IETF protocols and
+   that an AD's "pet peeve" cannot indefinitely block something.
+
+   This is not to say that the IESG never wields power.  When the IESG
+   sees a Working Group veering from its charter, or when a WG asks the
+   IESG to make the WG's badly designed protocol a standard, the IESG
+   will act.  In fact, because of its high workload, the IESG usually
+   moves in a reactive fashion.  It eventually approves most WG requests
+   for Internet Drafts to become RFCs, and usually only steps in when
+   something has gone very wrong.  Another way to think about this is
+   that the ADs are selected to think, not to just run the process.  The
+   quality of the IETF standards comes both from the review they get in
+   the Working Groups and the scrutiny that the WG review gets from the
+   ADs.
+
+
+
+
+
+
+Hoffman & Harris             Informational                      [Page 9]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   The IETF is run by rough consensus, and it is the IESG that judges
+   whether a WG has come up with a result that has community consensus.
+   (See Section 5.2 for more information on WG consensus.)  Because of
+   this, one of the main reasons that the IESG might block something
+   that was produced in a WG is that the result did not really gain
+   consensus in the IETF as a whole, that is, among all of the Working
+   Groups in all areas.  For instance, the result of one WG might clash
+   with a technology developed in a different Working Group.  An
+   important job of the IESG is to watch over the output of all the WGs
+   to help prevent IETF protocols that are at odds with each other.
+   This is why ADs are supposed to review the drafts coming out of areas
+   other than their own.
+
+3.2.3.  IAB (Internet Architecture Board)
+
+   The IAB is responsible for keeping an eye on the "big picture" of the
+   Internet, and it focuses on long-range planning and coordination
+   among the various areas of IETF activity.  The IAB stays informed
+   about important long-term issues in the Internet, and it brings these
+   topics to the attention of people it thinks should know about them.
+   The IAB web site is at http://www.iab.org/.
+
+   IAB members pay special attention to emerging activities in the IETF.
+   When a new IETF Working Group is proposed, the IAB reviews its
+   charter for architectural consistency and integrity.  Even before the
+   group is chartered, the IAB members are more than willing to discuss
+   new ideas with the people proposing them.
+
+   The IAB also sponsors and organizes the Internet Research Task Force
+   and convenes invitational workshops that provide in-depth reviews of
+   specific Internet architectural issues.  Typically, the workshop
+   reports make recommendations to the IETF community and to the IESG.
+
+   The IAB also:
+
+   o  Approves NomCom's IESG nominations
+
+   o  Acts as the appeals board for appeals against IESG actions
+
+   o  Appoints and oversees the RFC Editor
+
+   o  Approves the appointment of the IANA
+
+   o  Acts as an advisory body to ISOC
+
+   o  Oversees IETF liaisons with other standards bodies
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 10]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   Like the IESG, the IAB members are selected for multi-year positions
+   by the NomCom and are approved by the ISOC Board of Trustees.
+
+3.2.4.  IANA (Internet Assigned Numbers Authority)
+
+   The core registrar for the IETF's activities is the IANA.  Many
+   Internet protocols require that someone keep track of protocol items
+   that were added after the protocol came out.  Typical examples of the
+   kinds of registries needed are for TCP port numbers and MIME types.
+   The IAB has designated the IANA organization to perform these tasks,
+   and the IANA's activities are financially supported by ICANN, the
+   Internet Corporation for Assigned Names and Numbers.
+
+   Ten years ago, no one would have expected to see the IANA mentioned
+   on the front page of a newspaper.  IANA's role had always been very
+   low key.  The fact that IANA was also the keeper of the root of the
+   domain name system forced it to become a much more public entity, one
+   that was badly maligned by a variety of people who never looked at
+   what its role was.  Nowadays, the IETF is generally no longer
+   involved in the IANA's domain name and IP address assignment
+   functions, which are overseen by ICANN.
+
+   Even though being a registrar may not sound interesting, many IETF
+   participants will testify to how important IANA has been for the
+   Internet.  Having a stable, long-term repository run by careful and
+   conservative operators makes it much easier for people to experiment
+   without worrying about messing things up.  IANA's founder, Jon
+   Postel, was heavily relied upon to keep things in order while the
+   Internet kept growing by leaps and bounds, and he did a fine job of
+   it until his untimely death in 1998.
+
+3.2.5.  RFC Editor
+
+   The RFC Editor edits, formats, and publishes Internet Drafts as RFCs,
+   working in conjunction with the IESG.  An important secondary role is
+   to provide one definitive repository for all RFCs (see
+   http://www.rfc-editor.org).  Once an RFC is published, it is never
+   revised.  If the standard it describes changes, the standard will be
+   re-published in another RFC that "obsoletes" the first.
+
+   One of the most popular misconceptions in the IETF community is that
+   the role of the RFC Editor is performed by IANA.  In fact, the RFC
+   Editor is a separate job, although both the RFC Editor and IANA
+   involved the same people for many years.  The IAB approves the
+   organization that will act as RFC Editor and the RFC Editor's general
+   policy.  The RFC Editor is funded by IASA and can be contacted by
+   email at mailto:rfc-editor@rfc-editor.org.
+
+
+
+
+Hoffman & Harris             Informational                     [Page 11]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+3.2.6.  IETF Secretariat
+
+   There are, in fact, a few people who are paid to maintain the IETF.
+   The IETF Secretariat provides day-to-day logistical support, which
+   mainly means coordinating face-to-face meetings and running the
+   IETF-specific mailing lists (not the WG mailing lists).  The
+   Secretariat is also responsible for keeping the official Internet
+   Drafts directory up to date and orderly, maintaining the IETF web
+   site, and helping the IESG do its work.  It provides various tools
+   for use by the community and the IESG.  The IETF Secretariat is under
+   contract to IASA, which in turn is financially supported by the fees
+   of the face-to-face meetings.
+
+3.3.  IETF Mailing Lists
+
+   Anyone who plans to attend an IETF meeting should join the IETF
+   announcement mailing list, mailto:ietf-announce@ietf.org.  This is
+   where all of the meeting information, RFC announcements, and IESG
+   Protocol Actions and Last Calls are posted.  People who would like to
+   "get technical" may also join the IETF general discussion list,
+   ietf@ietf.org.  This is where discussions of cosmic significance are
+   held (Working Groups have their own mailing lists for discussions
+   related to their work).  Another mailing list, mailto:i-d-
+   announce@ietf.org, announces each new version of every Internet Draft
+   as it is published.
+
+   Subscriptions to these and other IETF-run mailing lists are handled
+   by a program called "mailman".  Mailman can be somewhat finicky about
+   the format of subscription messages, and sometimes interacts poorly
+   with email programs that make all email messages into HTML files.
+   Mailman will treat you well, however, if you format your messages
+   just the way it likes.
+
+   To join the IETF announcement list, for example, send email to
+   mailto:ietf-announce-request@ietf.org.  Enter the word 'subscribe'
+   (without the quotes) in the Subject line of the message and in the
+   message body.  To join the IETF discussion list, send email to
+   <mailto:ietf-request@ietf.org> and enter the word 'subscribe' as
+   explained above.  If you decide to withdraw from either list, use the
+   word 'unsubscribe'.  Your messages to mailman should have nothing
+   other than the commands 'subscribe' or 'unsubscribe' in them.  Both
+   lists are archived on the IETF web site,
+   http://www.ietf.org/maillist.html.
+
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 12]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   Do not, ever, under any circumstances, for any reason, send a request
+   to join a list to the list itself!  The thousands of people on the
+   list don't need, or want, to know when a new person joins.
+   Similarly, when changing email addresses or leaving a list, send your
+   request only to the "-request" address, not to the main list.  This
+   means you!!
+
+   The IETF discussion list is unmoderated.  This means that all can
+   express their opinions about issues affecting the Internet.  However,
+   it is not a place for companies or individuals to solicit or
+   advertise, as noted in [BCP45], "IETF Discussion List Charter".  It
+   is a good idea to read the whole RFC (it's short!) before posting to
+   the IETF discussion list.  Actually, the list does have two
+   "sergeants at arms" who keep an eye open for inappropriate postings,
+   and there is a process for banning persistent offenders from the
+   list, but fortunately this is extremely rare.
+
+   Only the Secretariat and certain IETF office holders can approve
+   messages sent to the announcement list, although those messages can
+   come from a variety of people.
+
+   Even though the IETF mailing lists "represent" the IETF membership at
+   large, it is important to note that attending an IETF meeting does
+   not mean you'll be automatically added to either mailing list.
+
+4.  IETF Meetings
+
+   The computer industry is rife with conferences, seminars,
+   expositions, and all manner of other kinds of meetings.  IETF face-
+   to-face meetings are nothing like these.  The meetings, held three
+   times a year, are week-long "gatherings of the tribes" whose primary
+   goal is to reinvigorate the WGs to get their tasks done, and whose
+   secondary goal is to promote a fair amount of mixing between the WGs
+   and the areas.  The cost of the meetings is paid by the people
+   attending and by the corporate host for each meeting (if any),
+   although IASA kicks in additional funds for things such as the audio
+   broadcast of some Working Group sessions.
+
+   For many people, IETF meetings are a breath of fresh air when
+   compared to the standard computer industry conferences.  There is no
+   exposition hall, few tutorials, and no big-name industry pundits.
+   Instead, there is lots of work, as well as a fair amount of time for
+   socializing.  IETF meetings are of little interest to sales and
+   marketing folks, but of high interest to engineers and developers.
+
+   Most IETF meetings are held in North America, because that's where
+   most of the participants are from; however, meetings are held on
+   other continents about once every year.  The past few meetings have
+
+
+
+Hoffman & Harris             Informational                     [Page 13]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   had about 1,300 attendees.  There have been more than 65 IETF
+   meetings so far, and a list of upcoming meetings is available on the
+   IETF web pages, http://www.ietf.org/meetings/0mtg-sites.txt.
+
+   Newcomers to IETF face-to-face meetings are often in a bit of shock.
+   They expect them to be like other standards bodies, or like computer
+   conferences.  Fortunately, the shock wears off after a day or two,
+   and many new attendees get quite animated about how much fun they are
+   having.  One particularly jarring feature of recent IETF meetings is
+   the use of wireless Internet connections throughout the meeting
+   space.  It is common to see people in a WG meeting apparently reading
+   email or perusing the web during presentations they find
+   uninteresting.  Remember, however, that they may also be consulting
+   the drafts under discussion, looking up relevant material online, or
+   following another meeting using instant messaging.
+
+4.1.  Registration
+
+   To attend an IETF meeting, you have to register and you have to pay
+   the registration fee.  The meeting site and advance registration are
+   announced about two months ahead of the meeting -- earlier if
+   possible.  An announcement goes out via email to the IETF-announce
+   mailing list, and information is posted on the IETF web site,
+   http://www.ietf.org, that same day.
+
+   To pre-register, you must submit your registration on the web.  You
+   may pre-register and pre-pay, pre-register and return to the web site
+   later to pay with a credit card, pre-register and pay on-site at the
+   meeting, or register and pay on-site.  To get a lower registration
+   fee, you must pay by the early registration deadline (about one week
+   before the meeting).  The registration fee covers all of the week's
+   meetings, the Sunday evening reception (cash bar), daily continental
+   breakfasts, and afternoon coffee and snack breaks.
+
+   Credit card payments on the web are encrypted and secure, or, if you
+   prefer, you can use Pretty Good Privacy (PGP) to send your payment
+   information to the Registrar (mailto:ietf-registrar@ietf.org).
+
+   Registration is open throughout the week of the meeting.  However,
+   the Secretariat highly recommends that attendees arrive for early
+   registration, usually beginning at noon on Sunday and continuing
+   throughout the Sunday evening reception.  The reception is a popular
+   event where you can get a small bite to eat and socialize with other
+   early arrivals.
+
+   Registered attendees (and there aren't any other kind) receive a
+   registration packet.  It contains much useful information, including
+   a general orientation sheet, the most recent agenda, and a name tag.
+
+
+
+Hoffman & Harris             Informational                     [Page 14]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   Attendees who pre-paid will also find their receipt in their packet.
+   It's worth noting that neither attendee names and addresses nor IETF
+   mailing lists are ever offered for sale.
+
+   In your registration packet is a sheet titled "Note Well".  You
+   should indeed read it carefully because it lays out the rules for
+   IETF intellectual property rights.
+
+   If you need to leave messages for other attendees, you can do so at
+   the cork boards that are often near the registration desk.  These
+   cork boards will also have last-minute meeting changes and room
+   changes.
+
+   You can also turn in lost-and-found items to the registration desk.
+   At the end of the meeting, anything left over from the lost and found
+   will usually be turned over to the hotel or brought back to the
+   Secretariat's office.
+
+   Incidentally, the IETF registration desk is often a convenient place
+   to arrange to meet people.  If someone says "meet me at
+   registration", they almost always mean the IETF registration desk,
+   not the hotel registration desk.
+
+4.2.  Take the Plunge and Stay All Week!
+
+   IETF meetings last from Monday morning through Friday lunchtime.
+   Associated meetings often take place on the preceding or following
+   weekends.  It is best to plan to be present the whole week, to
+   benefit from cross-fertilization between Working Groups and from
+   corridor discussions.  As noted below, the agenda is fluid, and there
+   have been many instances of participants missing important sessions
+   due to last-minute scheduling changes after their travel plans were
+   fixed.  Being present the whole week is the only way to avoid this
+   annoyance.
+
+   If you cannot find meetings all week to interest you, you can still
+   make the most of the IETF meeting by working between sessions.  Most
+   IETF attendees carry laptop computers, and it is common to see many
+   of them in the terminal room or in the hallways working during
+   meeting sessions.  There is often good wireless Internet coverage in
+   many places of the meeting venue (restaurants, coffee shops, and so
+   on), so catching up on email when not in meetings is a fairly common
+   task for IETFers.
+
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 15]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+4.3.  Newcomer Training
+
+   Newcomers are encouraged to attend the Newcomer Training, which is
+   especially designed for first-time attendees.  The orientation is
+   organized and conducted by the IETF EDU team and is intended to
+   provide useful introductory information.  The session covers what's
+   in the attendee packets, what all the dots on name tags mean, the
+   structure of the IETF, and many other essential and enlightening
+   topics for new IETFers.
+
+   Immediately following the Newcomers' Training is the IETF Standards
+   Process Orientation.  This session demystifies much of the standards
+   process by explaining what stages a document has to pass through on
+   its way to becoming a standard, and what has to be done to advance to
+   the next stage.
+
+   There is usually ample time at the end for questions.  The
+   Secretariat provides hard copies of the slides of the "IETF Structure
+   and Internet Standards Process" presentation -- these very useful
+   slides are also available online at www.ietf.org under "Educational
+   Materials".
+
+   The orientation is normally held on Sunday afternoon, along with
+   tutorials of interest to newcomers and old-timers alike.  Check the
+   agenda for exact times and locations.
+
+4.4.  Dress Code
+
+   Since attendees must wear their name tags, they must also wear shirts
+   or blouses.  Pants or skirts are also highly recommended.  Seriously
+   though, many newcomers are often embarrassed when they show up Monday
+   morning in suits, to discover that everybody else is wearing T-
+   shirts, jeans (shorts, if weather permits) and sandals.  There are
+   those in the IETF who refuse to wear anything other than suits.
+   Fortunately, they are well known (for other reasons) so they are
+   forgiven this particular idiosyncrasy.  The general rule is "dress
+   for the weather" (unless you plan to work so hard that you won't go
+   outside, in which case, "dress for comfort" is the rule!).
+
+4.5.  Seeing Spots Before Your Eyes
+
+   Some of the people at the IETF will have a little colored dot on
+   their name tag.  A few people have more than one.  These dots
+   identify people who are silly enough to volunteer to do a lot of
+   extra work.  The colors have the meanings shown here.
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 16]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   Color     Meaning
+   --------------------------------------
+   Blue      Working Group/BOF chair
+   Green     Host group
+   Red       IAB member
+   Yellow    IESG member
+   Orange    Nominating Committee member
+
+   (Members of the press wear orange-tinted badges.)
+
+   Local hosts are the people who can answer questions about the
+   terminal room, restaurants, and points of interest in the area.
+
+   It is important that newcomers to the IETF not be afraid to strike up
+   conversations with people who wear these dots.  If the IAB and IESG
+   members and Working Group and BOF chairs didn't want to talk to
+   anybody, they wouldn't be wearing the dots in the first place.
+
+4.6.  Terminal Room
+
+   One of the most important (depending on your point of view) things
+   the host does is provide Internet access for the meeting attendees.
+   In general, wired and wireless connectivity is excellent.  This is
+   entirely due to the Olympian efforts of the local hosts and their
+   ability to beg, borrow, and steal.  The people and companies that
+   donate their equipment, services, and time are to be heartily
+   congratulated and thanked.
+
+   Although preparation far in advance of the meeting is encouraged,
+   there may be some unavoidable "last minute" things that can be
+   accomplished in the terminal room.  It may also be useful to people
+   who need to make trip reports or status reports while things are
+   still fresh in their minds.
+
+   You need to be wearing your badge in order to get into the terminal
+   room.  The terminal room provides lots of power strips, lots of
+   Ethernet ports for laptops, wireless (for the people who don't need
+   Ethernet but want power), usually a printer for public use, and
+   sometimes workstations.  What it doesn't provide are terminals; the
+   name is historical.  The help desk in the terminal room is a good
+   place to ask questions about network failures, although they might
+   point you off to different networking staff.
+
+4.7.  Meals and Other Delights
+
+   Marshall Rose once remarked that the IETF was a place to go for "many
+   fine lunches and dinners".  Although it is true that some people eat
+   very well at the IETF, they find the food on their own; lunches and
+
+
+
+Hoffman & Harris             Informational                     [Page 17]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   dinners are not included in the registration fee.  The Secretariat
+   does provide appetizers at the Sunday evening reception (not meant to
+   be a replacement for dinner), continental breakfast every morning,
+   and (best of all) cookies, brownies, and other yummies during
+   afternoon breaks.
+
+   If you prefer to get out of the hotel for meals, the local host
+   usually provides a list of places to eat within easy reach of the
+   meeting site.
+
+4.8.  Social Event
+
+   Another of the most important things organized and managed by the
+   host is the IETF social event.  Sometimes, the social event is a
+   computer- or high-tech-related event.  At one Boston IETF, for
+   example, the social was dinner at the Computer Museum.  Other times,
+   the social might be a dinner cruise or a trip to an art gallery.
+   Note, however, that not all IETF meetings have social events.
+
+   Newcomers to the IETF are encouraged to attend the social event.  All
+   are encouraged to wear their name tags and leave their laptops
+   behind.  The social event is designed to give people a chance to meet
+   on a social, rather than technical, level.
+
+4.9.  Agenda
+
+   The agenda for the IETF meetings is a very fluid thing.  It is
+   typically sent to the IETF announcement list a few times prior to the
+   meeting, and it is also available on the web.  The final agenda is
+   included in the registration packets.  Of course, "final" in the IETF
+   doesn't mean the same thing as it does elsewhere in the world.  The
+   final agenda is simply the version that went to the printer.  The
+   Secretariat will post agenda changes on the bulletin board near the
+   IETF registration desk (not the hotel registration desk).  These late
+   changes are not capricious: they are made "just in time" as session
+   chairs and speakers become aware of unanticipated clashes.  The IETF
+   is too dynamic for agendas to be tied down weeks in advance.
+
+   Assignments for breakout rooms (where the Working Groups and BOFs
+   meet) and a map showing the room locations are also shown on the
+   agenda.  Room assignments can change as the agenda changes.  Some
+   Working Groups meet multiple times during a meeting, and every
+   attempt is made to have a Working Group meet in the same room for
+   each session.
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 18]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+4.10.  EDU to the Rescue
+
+   If certain aspects of the IETF still mystify you (even after you
+   finish reading the Tao), you'll want to drop in on the on-site
+   training offered by the Education (EDU) team.  These informal classes
+   are designed for newcomers and seasoned IETFers alike.  In addition
+   to the Newcomer Training, the EDU team offers workshops for document
+   editors and Working Group chairs, plus an in-depth security tutorial
+   that's indispensable for both novices and longtime IETF attendees.
+   EDU sessions are generally held on Sunday afternoons.  You'll find
+   more about the EDU team at http://edu.ietf.org/.
+
+4.11.  Where Do I Fit In?
+
+   The IETF is different things to different people.  There are many
+   people who have been very active in the IETF who have never attended
+   an IETF meeting.  You should not feel obligated to come to an IETF
+   meeting just to get a feel for the IETF.  The following guidelines
+   (based on stereotypes of people in various industries) might help you
+   decide whether you actually want to come and, if so, what might be
+   the best use of your time at your first meeting.
+
+4.11.1.  IS Managers
+
+   As discussed throughout this document, an IETF meeting is nothing
+   like any trade show you have attended.  IETF meetings are singularly
+   bad places to go if your intention is to find out what will be hot in
+   the Internet industry next year.  You can safely assume that going to
+   Working Group meetings will confuse you more than it will help you
+   understand what is happening, or will be happening, in the industry.
+
+   This is not to say that no one from the industry should go to IETF
+   meetings.  As an IS manager, you might want to consider sending
+   specific people who are responsible for technologies that are under
+   development in the IETF.  As these people read the current Internet
+   Drafts and the traffic on the relevant Working Group lists, they will
+   get a sense of whether or not their presence would be worthwhile for
+   your company or for the Working Groups.
+
+4.11.2.  Network Operators and ISPs
+
+   Running a network is hard enough without having to grapple with new
+   protocols or new versions of the protocols with which you are already
+   dealing.  If you work for the type of network that is always using
+   the very latest hardware and software, and you are following the
+   relevant Working Groups in your copious free time, you could
+   certainly find participating in the IETF valuable.  A fair amount of
+   IETF work also covers many other parts of operations of ISPs and
+
+
+
+Hoffman & Harris             Informational                     [Page 19]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   large enterprises, and the input of operators is quite valuable to
+   keep this work vibrant and relevant.  Many of the best operations
+   documents from the IETF come from real-world operators, not vendors
+   and academics.
+
+4.11.3.  Networking Hardware and Software Vendors
+
+   The image of the IETF being mostly ivory tower academics may have
+   been true in the past, but the jobs of typical attendees are now in
+   industry.  In most areas of the IETF, employees of vendors are the
+   ones writing the protocols and leading the Working Groups, so it's
+   completely appropriate for vendors to attend.  If you create Internet
+   hardware or software, and no one from your company has ever attended
+   an IETF meeting, it behooves you to come to a meeting if for no other
+   reason than to tell the others how relevant the meeting was or was
+   not to your business.
+
+   This is not to say that companies should close up shop during IETF
+   meeting weeks so everyone can go to the meeting.  Marketing folks,
+   even technical marketing folks, are usually safe in staying away from
+   the IETF as long as some of the technical people from the company are
+   at the meeting.  Similarly, it isn't required, or likely useful, for
+   everyone from a technical department to go, particularly if they are
+   not all reading the Internet Drafts and following the Working Group
+   mailing lists.  Many companies have just a few designated meeting
+   attendees who are chosen for their ability to do complete and useful
+   trip reports.  In addition, many companies have internal coordination
+   efforts and a standards strategy.  If a company depends on the
+   Internet for some or all of its business, the strategy should
+   probably cover the IETF.
+
+4.11.4.  Academics
+
+   IETF meetings are often excellent places for computer science folks
+   to find out what is happening in the way of soon-to-be-deployed
+   protocols.  Professors and grad students (and sometimes overachieving
+   undergrads) who are doing research in networking or communications
+   can get a wealth of information by following Working Groups in their
+   specific fields of interest.  Wandering into different Working Group
+   meetings can have the same effect as going to symposia and seminars
+   in your department.  Researchers are also, of course, likely to be
+   interested in IRTF activities.
+
+4.11.5.  Computer Trade Press
+
+   If you're a member of the press and are considering attending IETF,
+   we've prepared a special section of the Tao just for you -- please
+   see Section 10.2.
+
+
+
+Hoffman & Harris             Informational                     [Page 20]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+4.12.  Proceedings
+
+   IETF proceedings are compiled in the two months following each
+   meeting and are available on the web and on CD.  Be sure to look
+   through a copy -- the proceedings are filled with information about
+   IETF that you're not likely to find anywhere else.  For example,
+   you'll find snapshots of most WG charters at the time of the meeting,
+   giving you a better understanding of the evolution of any given
+   effort.
+
+   The proceedings sometimes start with an informative (and highly
+   entertaining) message.  Each volume contains the final (hindsight)
+   agenda, an IETF overview, area and Working Group reports, and slides
+   from the protocol and technical presentations.  The Working Group
+   reports and presentations are sometimes incomplete, if the materials
+   haven't been turned in to the Secretariat in time for publication.
+
+   An attendee list is also included, which contains names and
+   affiliations as provided on the registration form.  For information
+   about obtaining copies of the proceedings, see the web listing at
+   http://www.ietf.org/proceedings/directory.html.
+
+4.13.  Other General Things
+
+   The IETF Secretariat, and IETFers in general, are very approachable.
+   Never be afraid to approach someone and introduce yourself.  Also,
+   don't be afraid to ask questions, especially when it comes to jargon
+   and acronyms.
+
+   Hallway conversations are very important.  A lot of very good work
+   gets done by people who talk together between meetings and over
+   lunches and dinners.  Every minute of the IETF can be considered work
+   time (much to some people's dismay).
+
+   A "bar BOF" is an unofficial get-together, usually in the late
+   evening, during which a lot of work gets done over drinks.  Bar BOFs
+   spring up in many different places around an IETF meeting, such as
+   restaurants, coffee shops, and (if we are so lucky) pools.
+
+   It's unwise to get between a hungry IETFer (and there isn't any other
+   kind) and coffee break brownies and cookies, no matter how
+   interesting a hallway conversation is.
+
+   IETFers are fiercely independent.  It's safe to question opinions and
+   offer alternatives, but don't expect an IETFer to follow orders.
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 21]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   The IETF meetings, and the plenary session in particular, are not
+   places for vendors to try to sell their wares.  People can certainly
+   answer questions about their company and its products, but bear in
+   mind that the IETF is not a trade show.  This does not preclude
+   people from recouping costs for IETF-related T-shirts, buttons, and
+   pocket protectors.
+
+   There is always a "materials distribution table" near the
+   registration desk.  This desk is used to make appropriate information
+   available to the attendees (e.g., copies of something discussed in a
+   Working Group session, descriptions of online IETF-related
+   information).  Please check with the Secretariat before placing
+   materials on the desk; the Secretariat has the right to remove
+   material that he or she feels is not appropriate.
+
+   If you rely on your laptop during the meeting, it is a good idea to
+   bring an extra battery.  It is not always easy to find a spare outlet
+   in some meeting rooms, and using the wireless access can draw down
+   your battery faster than you might expect.  If you are sitting near a
+   power-strip in a meeting room, expect to be asked to plug and unplug
+   for others around you.  Many people bring an extension cord with
+   spare outlets, which is a good way to make friends with your neighbor
+   in a meeting.  If you need an outlet adapter, you should try to buy
+   it in advance because the one you need is usually easier to find in
+   your home country.
+
+5.  Working Groups
+
+   The vast majority of the IETF's work is done in many Working Groups;
+   at the time of this writing, there are about 115 different WGs.  (The
+   term "Working Group" is often seen capitalized, but probably not for
+   any good reason.)  [BCP25], "IETF Working Group Guidelines and
+   Procedures", is an excellent resource for anyone participating in WG
+   discussions.
+
+   A WG is really just a mailing list with a bit of adult supervision.
+   You "join" the WG by subscribing to the mailing list; all mailing
+   lists are open to anyone.  Anyone can post to a WG mailing list,
+   although most lists require non-subscribers to have their postings
+   moderated.  Each Working Group has one or two chairs.
+
+   More important, 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
+
+
+
+Hoffman & Harris             Informational                     [Page 22]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   charter.  In fact, some WG charters actually specify what the WG will
+   not do, particularly if there were some attractive but nebulous
+   topics brought up during the drafting of the charter.  The list of
+   all WG charters makes interesting reading for folks who want to know
+   what the different Working Groups are supposed to be doing.
+
+5.1.  Working Group Chairs
+
+   The role of the WG chairs is described in both [BCP11] and [BCP25].
+   The IETF EDU team also offers special training for WG chairs on
+   Sunday afternoons preceding IETF.
+
+   As volunteer cat-herders, a chair's first job is to determine the WG
+   consensus goals and milestones, keeping the charter up to date.
+   Next, often with the help of WG secretaries or document editors, the
+   chair must manage WG discussion, both on the list and by scheduling
+   meetings when appropriate.  Sometimes discussions get stuck on
+   contentious points and the chair may need to steer people toward
+   productive interaction and then declare when rough consensus has been
+   met and the discussion is over.  Sometimes chairs also manage
+   interactions with non-WG participants or the IESG, especially when a
+   WG document approaches publication.  Chairs have responsibility for
+   the technical and non-technical quality of WG output.  As you can
+   imagine given the mix of secretarial, interpersonal, and technical
+   demands, some Working Group chairs are much better at their jobs than
+   others.
+
+   When a WG has fulfilled its charter, it is supposed to cease
+   operations.  (Most WG mailing lists continue on after a WG is closed,
+   still discussing the same topics as the Working Group did.)  In the
+   IETF, it is a mark of success that the WG closes up because it
+   fulfilled its charter.  This is one of the aspects of the IETF that
+   newcomers who have experience with other standards bodies have a hard
+   time understanding.  However, some WG chairs never manage to get
+   their WG to finish, or keep adding new tasks to the charter so that
+   the Working Group drags on for many years.  The output of these aging
+   WGs is often not nearly as useful as the earlier products, and the
+   messy results are sometimes attributed to what's called "degenerative
+   Working Group syndrome".
+
+   There is an official distinction between WG drafts and independent
+   drafts, but in practice, sometimes there is not much procedural
+   difference.  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.
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 23]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   WG chairs are strongly advised to go to the WG leadership training
+   that usually happens on the Sunday preceding the IETF meeting.  There
+   is also usually a WG chairs lunch mid-week during the meeting where
+   chair-specific topics are presented and discussed.  If you're
+   interested in what they hear there, take a look at the slides at
+   http://edu.ietf.org/.
+
+5.2.  Getting Things Done in a Working Group
+
+   One fact that confuses many novices is that the face-to-face WG
+   meetings are much less important in the IETF than they are in most
+   other organizations.  Any decision made at a face-to-face meeting
+   must also gain consensus on the WG mailing list.  There are numerous
+   examples of important decisions made in WG meetings that are later
+   overturned on the mailing list, often because someone who couldn't
+   attend the meeting pointed out a serious flaw in the logic used to
+   come to the decision.  Finally, WG meetings aren't "drafting
+   sessions", as they are in some other standards bodies: in the IETF,
+   drafting is done elsewhere.
+
+   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.  Sometimes consensus is determined by "humming" --
+   if you agree with a proposal, you hum when prompted by the chair; if
+   you disagree, you keep your silence.  Newcomers find it quite
+   peculiar, but it works.  It is up to the chair to decide when the
+   Working Group has reached rough consensus.
+
+   The lack of formal voting has caused some very long delays for some
+   proposals, but most IETF participants who have witnessed rough
+   consensus after acrimonious debates feel that the delays often result
+   in better protocols.  (And, if you think about it, how could you have
+   "voting" in a group that anyone can join, and when it's impossible to
+   count the participants?)  Rough consensus has been defined in many
+   ways; a simple version is that it means that strongly held objections
+   must be debated until most people are satisfied that these objections
+   are wrong.
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 24]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   Some Working Groups have complex documents or a complex set of
+   documents (or even both).  Shaking all the bugs out of one or more
+   complex documents is a daunting task.  In order to help relieve this
+   problem, some Working Groups use "issue trackers", which are online
+   lists of the open issues with the documents, the status of the issue,
+   proposed fixes, and so on.  Using an issue tracker not only helps the
+   WG not to forget to do something important, it helps when someone
+   asks a question later about why something was done in a particular
+   fashion.
+
+   Another method that some Working Groups adopt is to have a Working
+   Group "secretary" to handle the juggling of the documents and the
+   changes.  The secretary can run the issue tracker if there is one, or
+   can simply be in charge of watching that all of the decisions that
+   are made on the mailing list are reflected in newer versions of the
+   documents.
+
+   One thing you might find helpful, and possibly even entertaining,
+   during Working Group sessions is to follow the running commentary on
+   the Jabber room associated with that Working Group.  The running
+   commentary is often used as the basis for the minutes of the meeting,
+   but it can also include jokes, sighs, and other extraneous chatter.
+   Jabber is a free, streaming XML technology mainly used for instant
+   messaging.  You can find pointers to Jabber clients for many
+   platforms at http://www.jabber.org.  The Jabber chatrooms have the
+   name of the Working Group followed by "@jabber.ietf.org".  Those
+   rooms are, in fact, available year-round, not just during IETF
+   meetings, and some are used by active Working Group participants
+   during protocol development.
+
+5.3.  Preparing for Working Group Meetings
+
+   The most important thing that everyone (newcomers and seasoned
+   experts) should do before coming to a face-to-face meeting is to read
+   the Internet Drafts and RFCs ahead of time.  WG meetings are
+   explicitly not for education: they are for developing the group's
+   documents.  Even if you do not plan to say anything in the meeting,
+   you should read the group's documents before attending so you can
+   understand what is being said.
+
+   It's up to the WG chair to set the meeting agenda, usually a few
+   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.
+
+
+
+
+Hoffman & Harris             Informational                     [Page 25]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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 are on the agenda at a face-to-face meeting, you should
+   probably come with a few slides prepared.  But don't come with a
+   tutorial; people are supposed to read the drafts in advance.
+   Projectors for laptop-based presentations are available in all the
+   meeting rooms.
+
+   And here's a tip for your slides in WG or plenary presentations:
+   don't put your company's logo on every one, even though that is a
+   common practice outside the IETF.  The IETF frowns on this kind of
+   corporate advertising (except for the meeting sponsor in the plenary
+   presentation), and most presenters don't even put their logo on their
+   opening slide.  The IETF is about technical content, not company
+   boosterism.  Slides are often plain black and white for legibility,
+   with color used only when it really adds clarity.  Again, the content
+   is the most important part of the slides, not how it's presented.
+
+5.4.  Working Group Mailing Lists
+
+   As we mentioned earlier, the IETF announcement and discussion mailing
+   lists are the central mailing lists for IETF activities.  However,
+   there are many other mailing lists related to IETF work.  For
+   example, every Working Group has its own discussion list.  In
+   addition, there are some long-term technical debates that have been
+   moved off of the IETF list onto lists created specifically for those
+   topics.  It is highly recommended that you follow the discussions on
+   the mailing lists of the Working Groups that you 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.  That's why IETF procedures require all decisions to
+   be confirmed "on the list" and you will often hear a WG chair say,
+   "Let's take it to the list" to close a discussion.
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 26]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   Many IETF discussion lists use either mailman or another list
+   manager, Majordomo.  They usually have a "-request" address that
+   handles the administrative details of joining and leaving the list.
+   (See Section 3.3 for more information on mailman.)  It is generally
+   frowned upon when such administrivia appears on the discussion
+   mailing list.
+
+   Most IETF discussion lists are archived.  That is, all of the
+   messages sent to the list are automatically stored on a host for
+   anonymous HTTP or FTP access.  Many such archives are listed online
+   at ftp://ftp.ietf.org/ietf-mail-archive/ or they are in a web-based
+   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!).
+   The Working Group charter listings at
+   http://www.ietf.org/html.charters/wg-dir.html are a useful source;
+   note that the page has links to old, concluded WGs.
+
+   Some WG lists apply size limits on messages, particularly to avoid
+   large documents or presentations landing in everyone's mailbox.  It
+   is well worth remembering that participants do not all have broadband
+   connections (and even those with broadband connections sometimes get
+   their mail on slow connections when they travel), so shorter messages
+   are greatly appreciated.  Documents can be posted as Internet Drafts;
+   presentation material can be posted to a web site controlled by the
+   sender or sent personally to people who ask for it.  Some WGs set up
+   special sites to hold these large documents so that senders can post
+   there first, then just send to the list the URL of the document.
+
+5.5.  Interim Working Group Meetings
+
+   Working Groups sometimes hold interim meetings between IETFs.
+   Interim meetings aren't a substitute for IETF meetings, however -- a
+   group can't decide to skip a meeting in a location they're not fond
+   of and meet in Cancun (or even someplace mundane) three weeks later,
+   for example.  Interim meetings require AD approval and need to be
+   announced at least one month in advance.  Location and timing need to
+   allow fair access for all participants.  Like regular IETF meetings,
+   someone needs to take notes and send them to
+   mailto:proceedings@ietf.org, and the group needs to take attendance.
+   Decisions tentatively made during an interim WG meeting still must be
+   ratified on the mailing list.
+
+6.  BOFs
+
+   In order to form a Working Group, you need a charter and someone who
+   is able to be chair.  In order to get those things, you need to get
+   people interested so that they can help focus the charter and
+   convince an Area Director that the project is worthwhile.  A face-
+
+
+
+Hoffman & Harris             Informational                     [Page 27]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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 Birds of a Feather (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 he or she thinks.  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 do 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, whereas others start from
+   scratch.
+
+   An advantage of having a draft before the BOF is to help focus the
+   discussion.  On the other hand, having a draft might tend to limit
+   what the other folks in the BOF want to do in the charter.  It's
+   important to remember that most BOFs are held in order to get support
+   for an eventual Working Group, not to get support for a particular
+   document.
+
+   Many BOFs don't turn into WGs for a variety of reasons.  A common
+   problem is that not enough people can agree on a focus for the work.
+   Another typical reason is that the work wouldn't end up being a
+   standard -- if, for example, the document authors don't really want
+   to relinquish change control to a WG.  (We'll discuss change control
+   later in this document.)  Only two meetings of a BOF can be scheduled
+   on a particular subject; either a WG has to form or the topic should
+   be dropped.
+
+7.  New to the IETF and Coming to a Meeting? 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.
+
+   If you're planning to participate in the IETF remotely, through
+   reading email lists and the proceedings, read on!
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 28]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+8.  RFCs and Internet Drafts
+
+   If you're a new IETF participant and are looking for a particular RFC
+   or Internet Draft, go to the RFC Editor's web pages, http://www.rfc-
+   editor.org/rfc.html.  That site also has links to other RFC
+   collections, many with search capabilities.  If you know the number
+   of the RFC you're looking for, go to the IETF RFC pages,
+   http://www.ietf.org/rfc.html.  For Internet Drafts, the best resource
+   is the IETF web site, http://www.ietf.org/ID.html, where you can
+   search by title and keyword.
+
+8.1.  Getting an RFC 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.
+
+   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 as follows:
+
+   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
+   [BCP9], "The Internet Standards Process".  Those who write drafts
+   that they hope will become IETF standards must read BCP 9 so that
+
+
+
+Hoffman & Harris             Informational                     [Page 29]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   they can follow the path of their document through the process.  BCP
+   9 (and various other documents that update it) goes into great detail
+   on a topic that is very often misunderstood, even by seasoned IETF
+   participants: different types of RFCs go through different processes
+   and have different rankings.  There are six kinds of RFCs:
+
+   o  Proposed standards
+
+   o  Draft standards
+
+   o  Internet standards (sometimes called "full standards")
+
+   o  Informational documents
+
+   o  Experimental protocols
+
+   o  Historic documents
+
+   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
+   [RFC1796], "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 that are introductory or that appeal to
+   a broad audience; however, that series has not been added to in a
+   long time.  Best Current Practice documents describe the application
+   of various technologies in the Internet.  The STD RFC sub-series was
+   created to identify RFCs that do in fact specify Internet standards.
+   Some STDs are actually sets of more than one RFC, and the "standard"
+   designation applies to the whole set of documents.
+
+8.2.  Letting Go Gracefully
+
+   The biggest reason some people do not want their documents put on the
+   IETF standards track is that they must give up change control of the
+   protocol.  That is, as soon as you propose that your protocol become
+   an IETF standard, you must fully relinquish control of the protocol.
+   If there is general agreement, parts of the protocol can be
+   completely changed, whole sections can be ripped out, new things can
+   be added, and the name can be changed.
+
+   Some authors find it very hard to give up control of their pet
+   protocol.  If you are one of those people, don't even think about
+   trying to get your protocol to become an IETF standard.  On the other
+   hand, if your goal is the best standard possible with the widest
+   implementation, then you might find the IETF process to your liking.
+
+
+
+
+Hoffman & Harris             Informational                     [Page 30]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   Incidentally, the change control on Internet standards doesn't end
+   when the protocol is put on the standards track.  The protocol itself
+   can be changed later for a number of reasons, the most common of
+   which is that implementors discover a problem as they implement the
+   standard.  These later changes are also under the control of the
+   IETF, not the editors of the standards document.
+
+   IETF standards exist so that people will use them to write Internet
+   programs that interoperate.  They don't exist to document the
+   (possibly wonderful) ideas of their authors, nor do they exist so
+   that a company can say, "We have an IETF standard".  If a standards-
+   track RFC only has one implementation (whereas two are required for
+   it to advance on the standards track), it was probably a mistake to
+   put it on the standards track in the first place.
+
+8.3.  Internet Drafts
+
+   First things first.  Every document that ends up in the RFC
+   repository starts life as an Internet Draft.  Internet Drafts are
+   tentative documents -- they're meant for readers to comment on, so
+   authors can mull over those comments and decide which ones to
+   incorporate in the draft.  In order to remind folks of their
+   tentativeness, Internet Drafts are automatically removed from the
+   online directories after six months.  They are most definitely not
+   standards or even specifications.  As [BCP9] says:
+
+   "An Internet Draft is NOT a means of 'publishing' a specification;
+   specifications are published through the RFC mechanism....  Internet
+   Drafts have no formal status, and are subject to change or removal at
+   any time.  Under no circumstances should an Internet Draft be
+   referenced by any paper, report, or Request-for-Proposal, nor should
+   a vendor claim compliance with an Internet Draft".
+
+   You can always tell a person who doesn't understand the IETF (or is
+   intentionally trying to fool people) when he or she brags about
+   having published an Internet Draft; it takes no significant effort.
+
+   When you submit an Internet Draft, you give some publication rights
+   to the IETF.  This is so that your Internet Draft is freely available
+   to everyone who wants to read and comment on it.  The rights you do
+   and don't give to the IETF are described in [BCP78], "IETF Rights in
+   Contributions".
+
+   There is a very useful checking tool at
+   http://tools.ietf.org/tools/idnits/idnits.pyht.  Using this tool
+   before you turn in an Internet Draft will help prevent the draft from
+   being rejected due to errors in form and formatting.
+
+
+
+
+Hoffman & Harris             Informational                     [Page 31]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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.  [RFC2223],
+   "Instructions to RFC Authors", describes the nroff formatting used by
+   the RFC Editor.  There is also a tool called "xml2rfc", available
+   from http://xml.resource.org/, that takes XML-formatted text and
+   turns it into a valid Internet Draft.
+
+   An Internet Draft can be either a Working Group draft or an
+   individual submission.  Working Group drafts are usually reviewed by
+   the Working Group before being accepted as a WG item, although the
+   chairs have the final say.
+
+   If you're interested in checking the status of a particular draft, or
+   can't remember its exact name, or want to find out which drafts a WG
+   is working on, two handy tools are available.  The "Internet Drafts
+   Database Interface", at
+   https://datatracker.ietf.org/public/idindex.cgi, lets you search for
+   a draft by author, Working Group, date, or filename.  The "I-D
+   Tracker", at https://datatracker.ietf.org/public/pidtracker.cgi, is
+   especially useful for authors who want to track the progress of their
+   draft as it makes its way through the publication process.
+
+   There are some informal rules for Internet Draft naming that have
+   evolved over the years.  Internet Drafts that revise existing RFCs
+   often have draft names with "bis" in them, meaning "again" or
+   "twice"; for example, a draft might be called "draft-someone-
+   rfc2345bis-00.txt".
+
+8.3.1.  Recommended Reading for Writers
+
+   Before you create the first draft of your Internet Draft, you should
+   read four documents:
+
+   o  More important than just explaining formatting, [RFC2223] 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.
+
+   o  [BCP22], "Guide for Internet Standards Writers", provides tips
+      that will help you write a standard that leads to
+      interoperability.  For instance, it explains how to choose the
+      right number of protocol options, how to respond to out-of-spec
+      behavior, and how to show state diagrams.
+
+
+
+Hoffman & Harris             Informational                     [Page 32]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   o  The online "Guidelines to Authors of Internet Drafts",
+      http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date
+      information about the process for turning in Internet Drafts, as
+      well as the most current boilerplate information that has to be
+      included in each Internet Draft.
+
+   o  When you think you are finished with the draft process and are
+      ready to request that the draft become an RFC, you should
+      definitely read "Checklist for Internet Drafts (I-Ds) Submitted
+      for RFC Publication", http://www.ietf.org/ID-Checklist.html, a
+      list of common issues 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.
+
+   Also, you should visit the IETF Tools web pages,
+   http://tools.ietf.org, where you'll find pointers to other tools that
+   will automate some of your work for the IETF.
+
+8.3.2.  Filenames and Other Matters
+
+   When you're ready to turn in your Internet Draft, send it to the
+   Internet Drafts administrator at mailto:internet-drafts@ietf.org.
+   There is a real person at the other end of this mail address, whose
+   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, you also tell the draft administrator your
+   proposed 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, authors
+   sometimes follow 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 administrator (and,
+   if it is an official WG draft, the WG chair) to come up with the
+   filename.  If you follow the naming guidelines given at
+   http://www.ietf.org/ietf/1id-guidelines.txt, chances are quite good
+   that your suggested filename will be fine.
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 33]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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 one or more
+   versions, such as when a personal effort is pulled into a Working
+   Group; when a draft has its filename changed, the number reverts to
+   -00.  Be sure to let the Internet Drafts administrator know the
+   previous name of the draft when such a name change occurs so that the
+   databases can be kept accurate.
+
+8.4.  Standards-Track RFCs
+
+   The procedure for creating and advancing a standard is described in
+   [BCP9].  After an Internet Draft has been sufficiently discussed and
+   there is rough consensus that what it says would be a useful
+   standard, it is presented to the IESG for consideration.  If the
+   draft is an official WG draft, the WG chair sends it to the
+   appropriate Area Director after it has gone through Working Group
+   last call.  If the draft is an individual submission, the draft's
+   author or editor submits it to the appropriate Area Director.  BCP 9
+   also describes the appeals process for people who feel that a Working
+   Group chair, an AD, or the IESG has made the wrong decision in
+   considering the creation or advancement of a standard.
+
+   After the I-D 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 it can sometimes cause
+   further changes to the draft.  It is also a time when people in the
+   WG who feel that they weren't heard can make their comments to
+   everyone.  The IETF last call is two weeks for drafts coming from WGs
+   and four weeks for individual submissions.
+
+   If the IESG approves the draft to become an Internet standard, they
+   ask the RFC Editor to publish it as a Proposed standard.  After it
+   has been a Proposed standard for at least six months, the RFC's
+   author (or the appropriate WG chair) can ask for it to become a Draft
+   standard.  Before that happens, however, someone needs to convince
+   the appropriate Area Director that there are at least two
+   independent, interoperable implementations of each part of the
+   standard.  This is a good test of the usefulness of the standard as a
+   whole, as well as an excellent way to check if the standard was
+   really readable.
+
+   A few things typically happen at this point.  First, it's common to
+   find that some of the specifications in the standard need to be
+   reworded because one implementor thought they meant one thing whereas
+   another implementor thought they meant something else.  Another
+   common occurrence is that none of the implementations actually tried
+
+
+
+Hoffman & Harris             Informational                     [Page 34]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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" (it can happen in
+   as little as four months, but this is rare).  This doesn't happen
+   often, and it 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 and looks for evidence of widespread
+   deployment before making a Draft standard an Internet standard.
+
+8.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.
+
+   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.
+
+   [STD3], "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 [BCP14], "Key words for use in
+   RFCs to Indicate Requirement Levels", which is widely referenced in
+   current Internet standards.  BCP 14 also specifically defines "must
+   not" and "should not", and it lists a few synonyms for the words
+   defined.
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 35]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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 it should be read by everyone who is
+   reading or writing IETF standards.  Although the definitions of
+   "must" and "must not" are fairly clear, the definitions of "should"
+   and "should not" cause a great deal of discussion in many WGs.  When
+   reviewing an Internet Draft, the question is often raised, "Should
+   that sentence have a MUST or a SHOULD in it?"  This is, indeed, a
+   very good question, because specifications shouldn't have gratuitous
+   MUSTs, but also should not have SHOULDs where a MUST is needed for
+   interoperability.  This goes to the crux of the question of over-
+   specifying and under-specifying requirements in standards.
+
+8.4.2.  Normative References in Standards
+
+   One aspect of writing IETF standards that trips up many novices (and
+   quite a few long-time IETF folks) 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 (sometimes called an "informative reference") is one that
+   is helpful to an implementor but is not needed.
+
+   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
+
+
+
+Hoffman & Harris             Informational                     [Page 36]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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.
+
+8.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 3.2.4, the main registry for all IETF standards has
+   long been IANA.  Because of the large and diverse kinds of registries
+   that standards require, IANA needs to have specific information about
+   how to register parameters, what not to register, who (if anyone)
+   will decide what is to be registered, and so on.
+
+   Anyone writing an Internet standard that may need a new IANA registry
+   or new values in a current IANA registry needs to read [BCP26],
+   "Guidelines for Writing an IANA Considerations Section in RFCs",
+   which describes how RFC authors should properly ask for IANA to start
+   or take over a registry.  IANA also maintains registries that were
+   started long before BCP 26 was produced.
+
+8.4.4.  Security Considerations
+
+   One thing that's required in every RFC and Internet Draft is a
+   "Security Considerations" section.  This section should describe any
+   known vulnerabilities of the protocol, possible threats, and
+   mechanisms or strategies to address them.  Don't gloss over this
+   section -- in particular, don't say, "Here's our protocol, if you
+   want security, just use IPsec".  This won't do at all, because it
+   doesn't answer the question of how IPsec interacts with your
+   protocol, and vice versa.  Be sure to check with your Working Group
+   chair if you're not sure how to handle this section in your draft.
+   See [BCP72], "Guidelines for Writing RFC Text on Security
+   Considerations", for more information on writing good security
+   considerations sections.
+
+8.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".
+
+
+
+Hoffman & Harris             Informational                     [Page 37]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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.  The official rules for all intellectual
+   property rights (IRP) in IETF documents (not just patents) are
+   covered in [BCP78] and [BCP79], "Intellectual Property Rights in IETF
+   Technology".  Everyone who participates in IETF Working Groups will
+   probably find these documents interesting because they lay out the
+   rules that everyone agrees to follow.
+
+   Patent holders who freely allow their patents to be used by people
+   implementing IETF standards often get a great deal of goodwill 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, consult the IETF IPR Disclosure Page
+   linked off the main IETF web site to determine how to proceed.
+   Intellectual property rights aren't mentioned in RFCs because RFCs
+   never change after they are published, but knowledge of IPR can
+   change at any time.  Therefore, an IPR list in an RFC could be
+   incomplete and mislead the reader.  [BCP9] provides specific text
+   that should be added to RFCs where the author knows of IPR issues.
+
+8.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, Historic, 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.)
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 38]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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, or whether they will work once deployed.  That is,
+   a specification might solve a problem, but if it is not clear that
+   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 (or proves that it works well), 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.
+
+   The IESG has created guidelines on how it chooses between
+   Informational and Experimental status:
+   http://www.ietf.org/u/ietfchair/info-exp.html.  If you are creating a
+   document that you think might become an Experimental RFC, knowing the
+   current thinking will help you justify your proposed choice.
+
+9.  How to Contribute to the IETF
+
+9.1.  What You Can Do
+
+   *Read* -- Review the Internet Drafts in your area of expertise and
+   comment on them in the Working Groups.  Participate in the discussion
+   in a friendly, helpful fashion, with the goal being the best Internet
+   standards possible.  Listen much more than you speak.  If you
+   disagree, debate the technical issues: never attack the people.
+
+   *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.
+
+
+
+Hoffman & Harris             Informational                     [Page 39]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   *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.
+
+9.2.  What Your Company Can Do
+
+   *Share* -- Avoid proprietary standards.  If you are an implementor,
+   exhibit a strong preference for IETF standards.  If the IETF
+   standards aren't as good as the proprietary standards, work to make
+   the IETF standards better.  If you're a purchaser, avoid products
+   that use proprietary standards that compete with the open standards
+   of the IETF and tell the companies you buy from that you are doing
+   so.
+
+   *Open Up* -- If your company controls a patent that is used in an
+   IETF standard, convince the company to make the patent available at
+   no cost to everyone who is implementing the standard.  In the past
+   few years, patents have caused a lot of serious problems for Internet
+   standards because they prevent some companies from being able to
+   freely implement the standards.  Fortunately, many companies have
+   generously offered unlimited licenses for particular patents in order
+   to help the IETF standards flourish.  These companies are usually
+   rewarded with positive publicity for the fact that they are not as
+   greedy or short-sighted as other patent-holders.
+
+   *Join* -- Become a member of ISOC.  More important, urge any company
+   that has benefited from the Internet to become a corporate member of
+   ISOC, since this has the greatest financial benefit for the group.
+   It will, of course, also benefit the Internet as a whole.
+
+10.  IETF and the Outside World
+
+10.1.  IETF and Other Standards Groups
+
+   As much as many IETF participants would like to think otherwise, the
+   IETF does not exist in a standards vacuum.  There are many (perhaps
+   too many) other standards organizations whose decisions affect the
+   Internet.  There are also a fair number of standards bodies that
+   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 does, and
+
+
+
+Hoffman & Harris             Informational                     [Page 40]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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 IETF has some liaisons with large
+   standards bodies, including the ITU (International Telecommunication
+   Union), the W3C, the Unicode Consortium, and ISO/IEC JTC1 (Joint
+   Technical Committee of the International Organization for
+   Standardization and International Electrotechnical Commission).  As
+   stated in the IAB Charter [BCP39], "Liaisons are kept as informal as
+   possible and must be of demonstrable value in improving the quality
+   of IETF specifications".  In practice, the IETF prefers liaisons to
+   take place directly at Working Group level, with formal relationships
+   and liaison documents in a backup role.
+
+   Some of these liaison tasks fall to the IESG, whereas others fall to
+   the IAB.  Detail-oriented readers will learn much about the formal
+   methods for dealing with other standards bodies in [BCP102], "IAB
+   Processes for Management of IETF Liaison Relationships", and
+   [BCP103], "Procedures for Handling Liaison Statements to and from the
+   IETF".  The best place to check to see whether the IETF has any
+   formal liaison at all is the list of IETF liaisons,
+   www.ietf.org/liaisonActivities.html.  The list shows that there are
+   many different liaisons to ISO/IEC JTC1 subcommittees.
+
+10.2.  Press Coverage of the IETF
+
+   Given that the IETF is one of the best-known bodies that is helping
+   move the Internet forward, it's natural for the computer press (and
+   even the trade press) to want to cover its actions.  In recent years,
+   a small number of magazines have assigned reporters and editors to
+   cover the IETF in depth over a long period of time.  These reporters
+   have ample scars from articles that they got wrong, incorrect
+   statements about the status of Internet Drafts, quotes from people
+   who are unrelated to the IETF work, and so on.
+
+   Major press errors fall into two categories: saying that the IETF is
+   considering something when in fact there is just an Internet Draft in
+   a Working Group, and saying that the IETF approved something when all
+   that happened was that an Informational RFC was published.  In both
+   cases, the press is not fully to blame for the problem, since they
+   are usually alerted to the story by a company trying to get publicity
+   for a protocol that they developed or at least support.  Of course, a
+   bit of research by the reporters would probably get them in contact
+   with someone who could straighten them out, such as a WG chair or an
+   Area Director.  The default press contact for the IETF is the IAD,
+   who can be reached at mailto:iad@ietf.org.
+
+
+
+Hoffman & Harris             Informational                     [Page 41]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   The fact that those reporters who've gotten it wrong once still 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!).
+   Furthermore, 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
+   doesn't have a press liaison, magazines or newspapers that run a
+   story with errors won't hear directly from the IETF and therefore
+   often won't know what they did wrong, so they might easily do it
+   again later.
+
+11.  Security Considerations
+
+   Section 8.4.4 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.
+
+
+
+
+Hoffman & Harris             Informational                     [Page 42]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+Appendix A.  Related Information
+
+A.1.  Why "the Tao"?
+
+   Pronounced "dow", Tao is the basic principle behind the teachings of
+   Lao-tse, a Chinese master.  Its familiar symbol is the black-and-
+   white yin-yang circle.  Taoism conceives the universe as a single
+   organism, and human beings as interdependent parts of a cosmic whole.
+   Tao is sometimes translated "the way", but according to Taoist
+   philosophy the true meaning of the word cannot be expressed in words.
+
+A.2.  Useful Email Addresses
+
+   Some useful email addresses are listed here.  These addresses may
+   change from time to time, and it's a good idea to check the IETF web
+   pages for the correct address before sending your mail.
+
+   Address                    Description
+   -----------------------------------------------------------------
+   agenda@ietf.org            Requests for agenda slots at IETF
+                              meetings
+
+   ietf-action@ietf.org       Requests for things to be done when you
+                              don't know exactly where to send the
+                              request
+
+   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-secretary@ietf.org    Questions for the Secretariat
+
+   ietf-web@ietf.org          Questions or comments about the IETF
+                              web site
+
+   internet-drafts@ietf.org   Internet Draft submissions and queries
+
+   proceedings@ietf.org       Where to send Working Group minutes and
+                              slides for the IETF Proceedings
+
+   iana@iana.org              Internet Assigned Numbers Authority
+
+   rfc-editor@rfc-editor.org  RFC Editor
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 43]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   statements@ietf.org        Incoming liaison statements from other
+                              organizations
+
+   Online upload pages are planned for the future to facilitate
+   submission of Internet Drafts, Proceedings, and Liaison statements.
+
+A.3.  Useful Documents and Files
+
+   The IETF web site, http://www.ietf.org, is the best source for
+   information about meetings, Working Groups, Internet Drafts, RFCs,
+   IETF email addresses, and much more.  Click on "Additional
+   Information" to find a variety of helpful links.  Internet Drafts and
+   other documents are also available in the "ietf" directory on
+   anonymous FTP sites worldwide.  For a listing of these sites, see
+   http://www.ietf.org/shadow.html.
+
+   Check the IESG web pages, http://www.ietf.org/iesg.html, to find up-
+   to-date information about drafts processed, RFCs published, and
+   documents in Last Call, as well as the monthly IETF status reports.
+
+A.4.  Acronyms and Abbreviations Used in the Tao
+
+   Some of the acronyms and abbreviations from this document are listed
+   below.
+
+   Term          Meaning
+   -----------------------------------------------------------------
+   AD            Area Director
+   BCP           Best Current Practice
+   BOF           Birds of a Feather
+   FAQ           Frequently Asked Question(s)
+   FYI           For Your Information (RFC)
+   IAB           Internet Architecture Board
+   IAD           IETF Administrative Director
+   IANA          Internet Assigned Numbers Authority
+   IAOC          IETF Administrative Oversight Committee
+   IASA          IETF Administrative Support Activity
+   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/
+   IPR           Intellectual property rights
+   IRTF          Internet Research Task Force, http://www.irtf.org/
+
+
+
+Hoffman & Harris             Informational                     [Page 44]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   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
+
+Appendix B.  IETF Guiding Principles
+
+   If you've gotten this far in the Tao, you've learned a lot about how
+   the IETF works.  What you'll find in this appendix summarizes much of
+   what you've read and adds a few new points to ponder.  Be sure to
+   read through all the principles; taken as a whole, they'll give you a
+   new slant on what makes the IETF work.
+
+B.1.  General
+
+   P1.   The IETF works by an open process and by rough consensus.  This
+         applies to all aspects of the operation of the IETF, including
+         creation of IETF documents and decisions on the processes that
+         are used.  But the IETF also observes experiments and running
+         code with interest, and this should also apply to the
+         operational processes of the organization.
+
+   P2.   The IETF works in areas where it has, or can find, technical
+         competence.
+
+   P3.   The IETF depends on a volunteer core of active participants.
+
+   P4.   Membership of the IETF or of its WGs is not fee-based or
+         organizationally defined, but is based upon self-identification
+         and active participation by individuals.
+
+B.2.  Management and Leadership
+
+   P5.   The IETF recognizes leadership positions and grants power of
+         decision to the leaders, but decisions are subject to appeal.
+
+   P6.   Delegation of power and responsibility are essential to the
+         effective working of the IETF.  As many individuals as possible
+         will be encouraged to take on leadership of IETF tasks.
+
+
+
+Hoffman & Harris             Informational                     [Page 45]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   P7.   Dissent, complaint, and appeal are a consequence of the IETF's
+         nature and should be regarded as normal events, but ultimately
+         it is a fact of life that certain decisions cannot be
+         effectively appealed.
+
+   P8.   Leadership positions are for fixed terms (although we have no
+         formal limitation on the number of terms that may be served).
+
+   P9.   It is important to develop future leaders within the active
+         community.
+
+   P10.  A community process is used to select the leadership.
+
+   P11.  Leaders are empowered to make the judgment that rough
+         consensus has been demonstrated.  Without formal membership,
+         there are no formal rules for consensus.
+
+B.3.  Process
+
+   P12.  Although the IETF needs clear and publicly documented process
+         rules for the normal cases, there should be enough flexibility
+         to allow unusual cases to be handled according to common sense.
+         We apply personal judgment and only codify when we're certain.
+         (But we do codify who can make personal judgments.)
+
+   P13.  Technical development work should be carried out by tightly
+         chartered and focused Working Groups.
+
+   P14.  Parts of the process that have proved impractical should be
+         removed or made optional.
+
+B.4.  Working Groups
+
+   P15.  Working Groups (WGs) should be primarily responsible for the
+         quality of their output, and therefore for obtaining early
+         review; WG chairs as WG leaders, backed up by the IETF
+         leadership, should act as a quality backstop.
+
+   P16.  WGs should be primarily responsible for assessing the negative
+         impact of their work on the Internet as a whole, and therefore
+         for obtaining cross-area review; the IETF leadership should act
+         as a cross-area backstop.
+
+   P17.  Early review of documents is more effective in dealing with
+         major problems than late review.
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 46]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   P18.  Area Directors (ADs) are responsible for guiding the formation
+         and chartering of WGs, for giving them direction as necessary,
+         and for terminating them.
+
+   P19.  WG chairs are responsible for ensuring that WGs execute their
+         charters, meet their milestones, and produce deliverables that
+         are ready for publication.
+
+   P20.  ADs are responsible for arranging backstop review and final
+         document approval.
+
+B.5.  Documents
+
+   P21.  IETF documents often start as personal drafts, may become WG
+         drafts, and are approved for permanent publication by a
+         leadership body independent of the WG or individuals that
+         produced them.
+
+   P22.  IETF documents belong to the community, not to their authors.
+         But authorship is recognized and valued, as are lesser
+         contributions than full authorship.
+
+   P23.  Technical quality and correctness are the primary criteria for
+         reaching consensus about documents.
+
+   P24.  IETF specifications may be published as Informational,
+         Experimental, Standards Track, or Best Current Practice.
+
+   P25.  IETF Standards Track specifications are not considered to be
+         satisfactory standards until interoperable independent
+         implementations have been demonstrated.  (This is the
+         embodiment of the "running code" slogan.)  But, on legal
+         advice, the IETF does not take responsibility for
+         interoperability tests and does not certify interoperability.
+
+   P26.  IETF processes are currently published as Best Current Practice
+         documents.
+
+   P27.  Useful information that is neither a specification nor a
+         process may be published as Informational.
+
+   P28.  Obsolete or deprecated specifications and processes may be
+         downgraded to Historic.
+
+   P29.  The standards track should distinguish specifications that have
+         been demonstrated to interoperate.
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 47]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   P30.  Standards Track and Best Current Practice documents must be
+         subject to IETF wide rough consensus (Last Call process).  WG
+         rough consensus is normally sufficient for other documents.
+
+   P31.  Substantive changes made after a document leaves a WG must be
+         referred back to the WG.
+
+   P32.  The IETF determines requirements for publication and archiving
+         of its documents.
+
+Informative References
+
+   [BCP9]     Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [BCP10]    Galvin, J., "IAB and IESG Selection, Confirmation, and
+              Recall Process: Operation of the Nominating and Recall
+              Committees", BCP 10, RFC 3777, June 2004.
+
+   [BCP11]    Hovey, R. and S. Bradner, "The Organizations Involved in
+              the IETF Standards Process", BCP 11, RFC 2028, October
+              1996.
+
+   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [BCP22]    Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [BCP25]    Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, September 1998.
+
+   [BCP26]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [BCP39]    Internet Architecture Board and B. Carpenter, "Charter of
+              the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
+              May 2000.
+
+   [BCP45]    Harris, S., "IETF Discussion List Charter", BCP 45, RFC
+              3005, November 2000.
+
+   [BCP72]    Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+              Text on Security Considerations", BCP 72, RFC 3552, July
+              2003.
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 48]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+   [BCP78]    Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
+              3978, March 2005.
+
+   [BCP79]    Bradner, S., "Intellectual Property Rights in IETF
+              Technology", BCP 79, RFC 3979, March 2005.
+
+   [BCP95]    Alvestrand, H., "A Mission Statement for the IETF", BCP
+              95, RFC 3935, October 2004.
+
+   [BCP101]   Austein, R. and B. Wijnen, "Structure of the IETF
+              Administrative Support Activity (IASA)", BCP 101, RFC
+              4071, April 2005.
+
+   [BCP102]   Daigle, L. and Internet Architecture Board, "IAB Processes
+              for Management of IETF Liaison Relationships", BCP 102,
+              RFC 4052, April 2005.
+
+   [BCP103]   Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
+              Handling Liaison Statements to and from the IETF", BCP
+              103, RFC 4053, April 2005.
+
+   [RFC1796]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
+              Standards", RFC 1796, April 1995.
+
+   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
+              RFC 2223, October 1997.
+
+   [STD3]     Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+Authors' Addresses
+
+   Paul Hoffman
+   VPN Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060
+   US
+
+   EMail: paul.hoffman@vpnc.org
+
+
+   Susan Harris
+   1722 Chandler Road
+   Ann Arbor, MI  48104
+   US
+
+   EMail: srh@umich.edu
+
+
+
+
+Hoffman & Harris             Informational                     [Page 49]
+
+RFC 4677                    The Tao of IETF               September 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Hoffman & Harris             Informational                     [Page 50]
+
-- 
cgit v1.2.3