summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4677.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4677.txt')
-rw-r--r--doc/rfc/rfc4677.txt2803
1 files changed, 2803 insertions, 0 deletions
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]
+