GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3160

Network Working Group S. Harris Request for Comments: 3160 Merit Network FYI: 17 August 2001 Obsoletes: 1718 Category: Informational

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

Status of this Memo

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

Copyright Notice

 Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

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

Table of Contents

 Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .   3
 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .   3
 1. What Is the IETF?  . . . . . . . . . . . . . . . . . . . . .   4
    1.1 Humble Beginnings. . . . . . . . . . . . . . . . . . . .   5
    1.2 The Hierarchy  . . . . . . . . . . . . . . . . . . . . .   5
        1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . .   5
        1.2.2 IESG . . . .  . . . . . . . . . . . . . .  . . . .   6
        1.2.3 IAB. . . . . . . . . . . . . . . . . . . . . . . .   7
        1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . .   8
        1.2.5 RFC Editor . . . . . . . . . . . . . . . . . . . .   8
        1.2.6 IETF Secretariat . . . . . . . . . . . . . . . . .   9
    1.3  IETF Mailing Lists. . . . . . . . . . . . . . . . . . .   9
 2.  IETF Meetings   . . . . . . . . . . . . . . . . . . . . . .  10
     2.1 Registration  . . . . . . . . . . . . . . . . . . . . .  11
     2.2 Newcomers' Orientation. . . . . . . . . . . . . . . . .  12
     2.3 Dress Code. . . . . . . . . . . . . . . . . . . . . . .  12
     2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . .  13
     2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . .  13
     2.6 Meals and Other Delights. . . . . . . . . . . . . . . .  14
     2.7 Social Event. . . . . . . . . . . . . . . . . . . . . .  14

Harris Informational [Page 1] RFC 3160 The Tao of IETF August 2001

     2.8 Agenda. . . . . . . . . . . . . . . . . . . . . . . . .  14
     2.9 Where Do I Fit In?. . . . . . . . . . . . . . . . . . .  15
         2.9.1  IS Managers. . . . . . . . . . . . . . . . . . .  15
         2.9.2  Network Operators and ISPs . . . . . . . . . . .  15
         2.9.3  Networking Hardware and Software Vendors . . . .  15
         2.9.4  Academics  . . . . . . . . . . . . . . . . . . .  16
         2.9.5  Computer Trade Press . . . . . . . . . . . . . .  16
     2.10 Proceedings. . . . . . . . . . . . . . . . . . . . . .  16
     2.11 Other General Things . . . . . . . . . . . . . . . . .  17
 3.  Working Groups. . . . . . . . . . . . . . . . . . . . . . .  18
     3.1 Working Group Chairs  . . . . . . . . . . . . . . . . . .18
     3.2 Getting Things Done in a Working Group. . . . . . . . .  19
     3.3 Preparing for Working Group Meetings    . . . . . . . .  19
     3.4 Working Group Mailing Lists   . . . . . . . . . . . . .  20
     3.5 Interim Working Group Meetings  . . . . . . . . . . . .  21
 4.  BOFs. . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
 5.  New to the IETF?  STOP HERE! (Temporarily). . . . . . . . .  22
 6.  RFCs and Internet Drafts  . . . . . . . . . . . . . . . . .  22
     6.1 Getting a Standard Published  . . . . . . . . . . . . .  22
     6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . .  24
     6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . .  24
         6.3.1 Recommended Reading for Writers . . . . . . . . .  25
         6.3.2 Filenames and Other Matters . . . . . . . . . . .  26
     6.4 Standards-Track RFCs  . . . . . . . . . . . . . . . . .  26
         6.4.1 Telling It Like It Is -- Using MUST and
               SHOULD and MAY. . . . . . . . . . . . . . . . . .  27
         6.4.2 Normative References in Standards . . . . . . . .  28
         6.4.3 IANA Considerations . . . . . . . . . . . . . . .  29
         6.4.4 Security Considerations . . . . . . . . . . . . .  29
         6.4.5 Patents in IETF Standards . . . . . . . . . . . .  30
     6.5 Informational and Experimental RFCs . . . . . . . . . .  31
 7. How to Contribute to the IETF -- What You Can Do . . . . . .  31
     7.1  What Your Company Can Do . . . . . . . . . . . . . . .  32
 8. IETF and the Outside World . . . . . . . . . . . . . . . . .  33
     8.1 IETF and Other Standards Groups . . . . . . . . . . . .  33
     8.2 Press Coverage of the IETF. . . . . . . . . . . . . . .  33
 9. References . . . . . . . . . . . . . . . . . . . . . . . . .  35
     9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . .  35
     9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . .  35
     9.3 Useful Documents and Files. . . . . . . . . . . . . . .  35
     9.4 Acronyms and Abbreviations Used in the Tao  . . . . . .  36
     9.5 Documents Cited in the Tao  . . . . . . . . . . . . . .  36
 Security Considerations . . . . . . . . . . . . . . . . . . . .  37
 Editor's Address  . . . . . . . . . . . . . . . . . . . . . . .  37
 Full Copyright Statement  . . . . . . . . . . . . . . . . . . .  38

Harris Informational [Page 2] RFC 3160 The Tao of IETF August 2001

Introduction

 Over the last several years, attendance at Internet Engineering Task
 Force (IETF) face-to-face meetings has grown phenomenally.  Many of
 the attendees are new to the IETF at each meeting, and many of those
 go on to become regular attendees.  When the meetings were smaller,
 it was relatively easy for a newcomer to get into the swing of
 things.  Today, however, a newcomer meets many more new people, some
 previously known only as the authors of documents or thought-
 provoking e-mail messages.
 This document describes many aspects of the IETF, with the goal of
 explaining to newcomers how the IETF works.  This will give them a
 warm, fuzzy feeling and enable them to make the meeting and the
 Working Group discussions more productive for everyone.
 Of course, it's true that many IETF participants don't go to the
 face-to-face meetings at all.  Instead, they're active on the mailing
 list of various IETF Working Groups.  Since the inner workings of
 Working Groups can be hard for newcomers to understand, this FYI
 provides the mundane bits of information that newcomers will need in
 order to become active participants.
 Many types of IETF documentation are mentioned in the Tao, from BCPs
 to RFCs and FYIs.  (BCPs make recommendations for Best Current
 Practices in the Internet; RFCs are the IETF's main technical
 documentation series, politely known as "Requests for Comments;" and
 FYIs provide topical and technical overviews that are introductory or
 appeal to a broad audience.  See Section 6 for more information.)
 The acronyms and abbreviations used in this document are usually
 expanded in place, and are explained fully in Section 9.

Acknowledgements

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

Harris Informational [Page 3] RFC 3160 The Tao of IETF August 2001

1. What Is the IETF?

 The Internet Engineering Task Force is a loosely self-organized group
 of people who contribute to the engineering and evolution of Internet
 technologies.  It is the principal body engaged in the development of
 new Internet standard specifications.  The IETF is unusual in that it
 exists as a collection of happenings, but is not a corporation and
 has no board of directors, no members, and no dues.
 Its mission includes:
  1. Identifying, and proposing solutions to, pressing operational and

technical problems in the Internet;

  1. Specifying the development or usage of protocols and the near-term

architecture to solve such technical problems for the Internet;

  1. Making recommendations to the Internet Engineering Steering Group

(IESG) regarding the standardization of protocols and protocol

    usage in the Internet;
  1. Facilitating technology transfer from the Internet Research Task

Force (IRTF) to the wider Internet community; and

  1. Providing a forum for the exchange of information within the

Internet community between vendors, users, researchers, agency

    contractors, and network managers.
 The IETF meeting is not a conference, although there are technical
 presentations.  The IETF is not a traditional standards organization,
 although many specifications are produced that become standards.  The
 IETF is made up of volunteers, many of whom meet three times a year
 to fulfill the IETF mission.
 There is no membership in the IETF.  Anyone may register for and
 attend any meeting.  The closest thing there is to being an IETF
 member is being on the IETF or Working Group mailing lists (see
 Section 1.3).  This is where the best information about current IETF
 activities and focus can be found.
 Of course, no organization can be as successful as the IETF is
 without having some sort of structure.  In the IETF's case, that
 structure is provided by other organizations, as described in BCP 11,
 "The Organizations Involved in the IETF Standards Process."  If you
 participate in the IETF and only read one BCP, this is the one you
 should read.

Harris Informational [Page 4] RFC 3160 The Tao of IETF August 2001

1.1 Humble Beginnings

 The first IETF meeting was held in January, 1986, at Linkabit in San
 Diego, with 21 attendees.  The 4th IETF, held at SRI in Menlo Park in
 October, 1986, was the first that non-government vendors attended.
 The concept of Working Groups was introduced at the 5th IETF meeting
 at the NASA Ames Research Center in California in February, 1987.
 The 7th IETF, held at MITRE in McLean, Virginia in July, 1987, was
 the first meeting with over 100 attendees.
 The 14th IETF meeting was held at Stanford University in July 1989.
 It marked a major change in the structure of the IETF universe.  The
 IAB (then Internet Activities Board, now Internet Architecture
 Board), which until that time oversaw many "task forces," changed its
 structure to leave only two: the IETF and the IRTF.  The IRTF is
 tasked to consider long-term research problems in the Internet.  The
 IETF also changed at that time.
 After the Internet Society (ISOC) was formed in January, 1992, the
 IAB proposed to ISOC that the IAB's activities should take place
 under the auspices of the Internet Society.  During INET92 in Kobe,
 Japan, the ISOC Trustees approved a new charter for the IAB to
 reflect the proposed relationship.
 The IETF met in Amsterdam, The Netherlands, in July 1993.  This was
 the first IETF meeting held in Europe, and the US/non-US attendee
 split was nearly 50/50.  One in five IETF meetings are now held in
 Europe or Asia, and the number of non-US attendees continues to be
 high -- about 50%, even at meetings held in the US.

1.2 The Hierarchy

1.2.1 ISOC (Internet Society)

 The Internet Society is an international, non-profit, membership
 organization that fosters the expansion of the Internet.  One of the
 ways that ISOC does this is through financial and legal support of
 the other "I" groups described here, particularly the IETF.  ISOC's
 oversight of the IETF is remarkably hands-off, so many IETF
 participants don't even know about it.  ISOC provides insurance
 coverage for many of the people in the IETF process, and acts as a
 public relations channel for the times that one of the "I" groups
 wants to say something to the press.  The ISOC is one of the major
 unsung (and under-funded) heroes of the Internet.

Harris Informational [Page 5] RFC 3160 The Tao of IETF August 2001

1.2.2 IESG (Internet Engineering Steering Group)

 The IESG is responsible for technical management of IETF activities
 and the Internet standards process.  It administers the process
 according to the rules and procedures that have been ratified by the
 ISOC Trustees.  However, the IESG doesn't do much direct leadership,
 such as the kind you will find in many other standards organizations.
 The IESG ratifies or corrects the output from the IETF's Working
 Groups, gets WGs started and finished, and makes sure that non-WG
 drafts that are about to become RFCs are correct.
 The IESG consists of the Area Directors ("ADs"), who are selected by
 the Nominations Committee (which is usually called "Nomcom") and are
 appointed for two years.  The process for choosing the members of the
 IESG is detailed in BCP 10, "IAB and IESG Selection, Confirmation,
 and Recall Process:  Operation of the Nominating and Recall
 Committees."
 The current areas and abbreviations are:
  1. Applications (APP) Protocols seen by user programs, such as

e-mail and the Web

  1. General (GEN) Catch-all for WGs that don't fit in other

areas (which is very few)

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

information

  1. Operations and Operational aspects, network monitoring,

Management (OPS) and configuration

  1. Routing (RTG) Getting packets to their destinations
  2. Security (SEC) Authentication and privacy
  3. Transport (TSV) Special services for special packets
  4. User Services (USV) Support for end users and user support

organizations

 Because the IESG has a great deal of influence on whether Internet
 Drafts become RFCs, many people look at the ADs as somewhat godlike
 creatures.  IETF participants sometimes reverently ask an Area
 Director for their opinion on a particular subject.  However, most
 ADs are nearly indistinguishable from mere mortals and rarely speak
 from mountaintops.  In fact, when asked for specific technical
 comments, the ADs may often defer to members at large whom they feel
 have more knowledge than they do in that area.
 The ADs for a particular area are expected to know more about the
 combined work of the WGs in that area than anyone else.  On the other
 hand, the entire IESG discusses each Internet Draft that is proposed
 to become an RFC.  At least two IESG members must express concerns
 before a draft can be blocked from moving forward.  These checks help

Harris Informational [Page 6] RFC 3160 The Tao of IETF August 2001

 ensure that an AD's "pet project" doesn't make it onto the standards
 track if it will have a negative effect on the rest of the IETF
 protocols.
 This is not to say that the IESG never wields power.  When the IESG
 sees a Working Group veering from its charter, or when a WG asks the
 IESG to make the WG's badly designed protocol a standard, the IESG
 will act.  In fact, because of its high workload, the IESG usually
 moves in a reactive fashion.  It approves most WG requests for
 Internet Drafts to become RFCs, and usually only steps in when
 something has gone very wrong.  Another way to think about this is
 that the ADs are selected to think, not to just run the process.  The
 quality of the IETF standards comes both from the review they get in
 the Working Groups and the review that the WG review gets from the
 ADs.
 The IETF is run by rough consensus, and it is the IESG that decides
 if a WG has come up with a result that has a real consensus.  Because
 of this, one of the main reasons that the IESG might block something
 that was produced in a WG is that the result did not really gain
 consensus in the IETF as a whole, that is, among all of the Working
 Groups in all areas.  For instance, the result of one WG might clash
 with a technology developed in a different Working Group.  An
 important job of the IESG is to watch over the output of all the WGs
 to help prevent IETF protocols that are at odds with each other.
 This is why ADs are supposed to review the drafts coming out of areas
 other than their own.

1.2.3 IAB (Internet Architecture Board)

 The IAB is responsible for keeping an eye on the "big picture" of the
 Internet, and focuses on long-range planning and coordination among
 the various areas of IETF activity.  The IAB stays informed about
 important long-term issues in the Internet, and brings these topics
 to the attention of people they think should know about them.
 IAB members pay special attention to emerging activities in the IETF.
 When a new IETF working group is proposed, the IAB reviews its
 charter for architectural consistency and integrity.  Even before the
 group is chartered, the IAB members are more than willing to discuss
 new ideas with the people proposing them.
 The IAB also sponsors and organizes the Internet Research Task Force,
 and convenes invitational workshops that provide in-depth reviews of
 specific Internet architectural issues.  Typically, the workshop
 reports make recommendations to the IETF community and to the IESG.

Harris Informational [Page 7] RFC 3160 The Tao of IETF August 2001

 The IAB also:
  1. Approves Nomcom's IESG nominations
  2. Acts as the appeals board for appeals against IESG actions
  3. Appoints and oversees the RFC Editor
  4. Approves the appointment of the IANA
  5. Acts as an advisory body to the ISOC
  6. Oversees IETF liaisons with other standards bodies
 Like the IESG, the IAB members are selected for multi-year positions
 by the Nomcom, and are approved by the Board of Trustees of the ISOC.

1.2.4 IANA (Internet Assigned Numbers Authority)

 The core registrar for the IETF's activities is the IANA.  Many
 Internet protocols require that someone keep track of protocol items
 that were added after the protocol came out.  Typical examples of the
 kinds of registries needed are for TCP port numbers and MIME types.
 The IAB has designated the IANA organization to perform these tasks,
 and the IANA's activities are financially supported by ICANN, the
 Internet Corporation for Assigned Names and Numbers.
 Five years ago, no one would have expected to ever see the IANA
 mentioned on the front page of a newspaper.  IANA's role had always
 been very low key.  The fact that IANA was also the keeper of the
 root of the domain name system forced it to become a much more public
 entity, one which was badly maligned by a variety of people who never
 looked at what its role was.  Nowadays the IETF is generally no
 longer involved in the IANA's domain name and IP address assignment
 functions, which are overseen by ICANN.
 Even though being a registrar may not sound interesting, many IETF
 participants will testify to how important IANA has been for the
 Internet.  Having a stable, long-term repository run by careful and
 conservative operators makes it much easier for people to experiment
 without worrying about messing things up.  IANA's founder, Jon
 Postel, was heavily relied upon to keep things in order while the
 Internet kept growing by leaps and bounds, and he did a fine job of
 it until his untimely death in 1998.

1.2.5 RFC Editor

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

Harris Informational [Page 8] RFC 3160 The Tao of IETF August 2001

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

1.2.6 IETF Secretariat

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

1.3 IETF Mailing Lists

 Anyone who plans to attend an IETF meeting should join the IETF
 announcement mailing list, "ietf-announce@ietf.org".  This is where
 all of the meeting information, Internet Draft and RFC announcements,
 and IESG Protocol Actions and Last Calls are posted.  People who
 would like to "get technical" may also join the IETF discussion list,
 "ietf@ietf.org".  This is where discussions of cosmic significance
 are held (Working Groups have their own mailing lists for discussions
 related to their work).
 Subscriptions to these and other IETF mailing lists are handled by a
 program called Majordomo.  Majordomo tends to be somewhat finicky
 about the format of subscription messages, and interacts poorly with
 email programs that make all email messages into HTML files.
 Majordomo will treat you well, however, if you format your messages
 just the way it likes.  To join the IETF announcement list, for
 example, send email to:
    ietf-announce-request@ietf.org
 Enter the word 'subscribe' (without the quotes) in the Subject line
 of the message and in the message body.  To join the IETF discussion
 list, send email to:
    ietf-request@ietf.org

Harris Informational [Page 9] RFC 3160 The Tao of IETF August 2001

 and enter the word 'subscribe' as explained above.  If you decide to
 withdraw from either list, use the word 'unsubscribe.' Your messages
 to Majordomo should have nothing other than the commands 'subscribe'
 or 'unsubscribe' in them.
 Both lists are archived on the IETF web site:
    http://www.ietf.org/maillist.html
 Do not, ever, under any circumstances, for any reason, send a request
 to join a list to the list itself!  The thousands of people on the
 list don't need, or want, to know when a new person joins.
 Similarly, when changing e-mail addresses or leaving a list, send
 your request only to the "-request" address, not to the main list.
 This means you!!
 The IETF discussion list is unmoderated.  This means that anyone can
 express their opinions about issues affecting the Internet.  However,
 it is not a place for companies or individuals to solicit or
 advertise, as noted in "IETF Discussion List Charter," RFC 3005.  It
 is a good idea to read the whole RFC (it's short!) before posting to
 the IETF discussion list.
 Only the Secretariat can send messages to the announcement list.
 Even though the IETF mailing lists "represent" the IETF membership at
 large, it is important to note that attending an IETF meeting does
 not mean you'll be automatically added to either mailing list.

2. IETF Meetings

 The computer industry is rife with conferences, seminars,
 expositions, and all manner of other kinds of meetings.  IETF face-
 to-face meetings are nothing like these.  The meetings, held three
 times a year, are week-long dweebfests whose primary goal is to
 reinvigorate the WGs to get their tasks done, and whose secondary
 goal is to promote a fair amount of mixing between the WGs and the
 areas.  The cost of the meetings is paid by the people attending and
 by the corporate host for each meeting, although ISOC kicks in
 additional funds for things like the multicast simulcast of some
 Working Group sessions.
 For many people, IETF meetings are a breath of fresh air when
 compared to the standard computer industry conferences.  There is no
 exposition hall, few tutorials, and no big-name industry pundits.
 Instead, there is lots of work, as well as a fair amount of time for
 socializing.  IETF meetings are of little interest to sales and
 marketing folks, but of high interest to engineers and developers.

Harris Informational [Page 10] RFC 3160 The Tao of IETF August 2001

 Most IETF meetings are held in North America, because that's where
 most of the participants are from; however, meetings are held on
 other continents about once every year or two.  The past few meetings
 have had about 2,500 attendees.  There have been over 50 IETF
 meetings so far, and a list of upcoming meetings is available on the
 IETF web pages, http://www.ietf.org/meetings/0mtg-sites.txt.
 Newcomers to IETF face-to-face meetings are often in a bit of shock.
 They expect them to be like other standards bodies, or like computer
 conferences.  Fortunately, the shock wears off after a day or two,
 and many new attendees get quite animated about how much fun they are
 having.  One particularly jarring feature of recent IETF meetings is
 the use of wireless Internet connections throughout the meeting
 space.  It is common to see half the people in a WG meeting reading
 e-mail or perusing the web during presentations they find
 uninteresting.

2.1 Registration

 To attend an IETF meeting you have to register and you have to pay
 the registration fee.  The meeting site and advance registration are
 announced about two months ahead of the meeting -- earlier if
 possible.  An announcement goes out via e-mail to the IETF-announce
 mailing list, and information is posted on the IETF web site,
 http://www.ietf.org, that same day.
 To pre-register, you must submit your registration on the Web.  You
 may pre-register and pre-pay, pre-register and return to the Web site
 later to pay with a credit card, pre-register and pay on-site at the
 meeting, or register and pay on-site.  To get a lower registration
 fee, you must pay by the early registration deadline (about one week
 before the meeting).  The registration fee covers all of the week's
 meetings, the Sunday evening reception (cash bar), daily continental
 breakfasts, and afternoon coffee breaks.
 Credit card payments on the web are encrypted and secure, or, if you
 prefer, you can use PGP to send your payment information to the
 Registrar (ietf-registrar@ietf.org).
 Registration is open throughout the week of the meeting.  However,
 the Secretariat highly recommends that attendees arrive for early
 registration, beginning at noon on Sunday and continuing throughout
 the 5:00 Sunday evening reception.  The reception is a popular event
 where you can get a bite to eat and socialize with other early
 arrivals.

Harris Informational [Page 11] RFC 3160 The Tao of IETF August 2001

 Registered attendees (and there aren't any other kind) receive a
 registration packet.  It contains much useful information, including
 a general orientation sheet, the most recent agenda, and a name tag.
 Attendees who pre-paid will also find their receipt in their packet.
 It's worth noting that neither attendee names and addresses or IETF
 mailing lists are ever offered for sale.

2.2 Newcomers' Orientation

 Newcomers are encouraged to attend the Newcomers' Orientation, which
 is especially designed for first-time attendees.  The orientation is
 organized and conducted by the IETF Secretariat, and is intended to
 provide useful introductory information.  The orientation is
 typically about 30 minutes long and covers what's in the attendee
 packets, what all the dots on name tags mean, the structure of the
 IETF, and many other essential and enlightening topics for new
 IETFers.
 Immediately following the Newcomers' Orientation is the IETF
 Standards Process Orientation.  This session demystifies much of the
 standards process by explaining what stages a document has to pass
 through on its way to becoming a standard, and what has to be done to
 advance to the next stage.  The Standards Process Orientation also
 lasts about 30 minutes.
 There is ample time at the end for questions.  The Secretariat also
 provides handouts that include an overview of the IETF, a list of
 important files available online, and hard copies of the slides of
 the "IETF Structure and Internet Standards Process" presentation.
 These very useful slides are also available online at www.ietf.org
 under "Additional Information".
 The orientation is held on Sunday afternoon before the 5:00 p.m.
 reception (check the agenda for exact time and location).  Be advised
 that attending the orientation does NOT mean you can go to the
 reception early!

2.3 Dress Code

 Since attendees must wear their name tags, they must also wear shirts
 or blouses.  Pants or skirts are also highly recommended.  Seriously
 though, many newcomers are often embarrassed when they show up Monday
 morning in suits, to discover that everybody else is wearing t-
 shirts, jeans (shorts, if weather permits) and sandals.  There are
 those in the IETF who refuse to wear anything other than suits.
 Fortunately, they are well known (for other reasons) so they are

Harris Informational [Page 12] RFC 3160 The Tao of IETF August 2001

 forgiven this particular idiosyncrasy.  The general rule is "dress
 for the weather" (unless you plan to work so hard that you won't go
 outside, in which case, "dress for comfort" is the rule!).

2.4 Seeing Spots Before Your Eyes

 Some of the people at the IETF will have a little colored dot on
 their name tag.  A few people have more than one.  These dots
 identify people who are silly enough to volunteer to do a lot of
 extra work.  The colors have the following meanings:
    blue    -  Working Group/BOF chair
    green   -  Host group
    red     -  IAB member
    yellow  -  IESG member
    orange  -  Nominating Committee member
 (Members of the press wear orange-tinted badges.)
 Local hosts are the people who can answer questions about the
 terminal room, restaurants, and points of interest in the area.
 It is important that newcomers to the IETF not be afraid to strike up
 conversations with people who wear these dots.  If the IAB and IESG
 members and Working Group and BOF chairs didn't want to talk to
 anybody, they wouldn't be wearing the dots in the first place.

2.5 Terminal Room

 One of the most important (depending on your point of view) things
 the host does is provide Internet access for the meeting attendees.
 In general, wired and wireless connectivity is excellent.  This is
 entirely due to the Olympian efforts of the local hosts, and their
 ability to beg, borrow and steal.  The people and companies who
 donate their equipment, services and time are to be heartily
 congratulated and thanked.
 While preparation far in advance of the meeting is encouraged, there
 may be some unavoidable "last minute" things that can be accomplished
 in the terminal room.  It may also be useful to people who need to
 make trip reports or status reports while things are still fresh in
 their minds.  The terminal room provides workstations, one or two
 printers, and ports for laptops.

Harris Informational [Page 13] RFC 3160 The Tao of IETF August 2001

2.6 Meals and Other Delights

 Marshall Rose once remarked that the IETF was a place to go for "many
 fine lunches and dinners."  While it is true that some people eat
 very well at the IETF, they find the food on their own; lunches and
 dinners are not included in the registration fee.  The Secretariat
 does provide appetizers at the Sunday evening reception (not meant to
 be a replacement for dinner), continental breakfast every morning,
 and (best of all) cookies, brownies and other yummies during
 afternoon breaks.
 If you prefer to get out of the hotel for meals, the local host
 usually provides a list of places to eat within easy reach of the
 meeting site.

2.7 Social Event

 Another of the most important things organized and managed by the
 host is the IETF social event.  Sometimes, the social event is a
 computer or high-tech related event.  At the Boston IETF, for
 example, the social was dinner at the Computer Museum.  Other times,
 the social might be a dinner cruise or a trip to an art gallery.
 Newcomers to the IETF are encouraged to attend the social event.
 Everyone is encouraged to wear their name tags and leave their
 laptops behind.  The social event is designed to give people a chance
 to meet on a social, rather than technical, level.

2.8 Agenda

 The agenda for the IETF meetings is a very fluid thing.  It is sent,
 updated, to the IETF announcement list three times prior to the
 meeting, and is also available on the web.  The agenda for the 50th
 IETF, for example, is at http://www.ietf.org/meetings/agenda_50.html.
 The final agenda is included in the registration packets.  Of course,
 "final" in the IETF doesn't mean the same thing as it does elsewhere
 in the world.  The final agenda is simply the version that went to
 the printer.  The Secretariat will post agenda changes on the
 bulletin board near the IETF registration desk (not the hotel
 registration desk).
 Assignments for breakout rooms (where the Working Groups and BOFs
 meet) and a map showing the room locations are also shown on the
 agenda.  Room assignments can change as the agenda changes.  Some
 Working Groups meet multiple times during a meeting and every attempt
 is made to have a Working Group meet in the same room for each
 session.

Harris Informational [Page 14] RFC 3160 The Tao of IETF August 2001

2.9 Where Do I Fit In?

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

2.9.1 IS Managers

 As discussed throughout this document, an IETF meeting is nothing
 like any trade show you have attended.  IETF meetings are singularly
 bad places to go if your intention is to find out what will be hot in
 the Internet industry next year.  You can safely assume that going to
 Working Group meetings will confuse you more than it will help you
 understand what is happening, or will be happening, in the industry.
 This is not to say that no one from industry should go to IETF
 meetings.  As an IS manager, you might want to consider sending
 specific people who are responsible for technologies that are under
 development in the IETF.  As these people read the current Internet
 Drafts and the traffic on the relevant Working Group lists, they will
 get a sense of whether or not their presence would be worthwhile for
 your company or for the Working Groups.

2.9.2 Network Operators and ISPs

 Running a network is hard enough without having to grapple with new
 protocols or new versions of the protocols with which you are already
 dealing.  If you work for the type of network that is always using
 the very latest hardware and software, and you are following the
 relevant Working Groups in your copious free time, you might find
 attending the IETF meeting valuable.  The closer you are to the
 bleeding edge of networking, particularly in the areas of routing and
 switching, the more likely it is that you will be able to learn and
 contribute at an IETF meeting.

2.9.3 Networking Hardware and Software Vendors

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

Harris Informational [Page 15] RFC 3160 The Tao of IETF August 2001

 reason than to tell the others how relevant the meeting was or was
 not to your business.
 This is not to say that companies should close up shop during IETF
 meeting weeks so everyone can go to the meeting.  Marketing folks,
 even technical marketing folks, are usually safe in staying away from
 the IETF as long as some of the technical people from the company are
 at the meeting.  Similarly, it isn't required, or likely useful, for
 everyone from a technical department to go, particularly if they are
 not all reading the Internet Drafts and following the Working Group
 mailing lists.  Many companies have just a few designated meeting
 attendees who are chosen for their ability to do complete and useful
 trip reports.

2.9.4 Academics

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

2.9.5 Computer Trade Press

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

2.10 Proceedings

 IETF proceedings are compiled in the two months following each
 meeting, and are available on the web, on CD, and in print.  Be sure
 to look through a copy -- the proceedings are filled with information
 about IETF that you're not likely to find anywhere else.  For
 example, you'll find snapshots of most WG charters at the time of the
 meeting, giving you a better understanding of the evolution of any
 given effort.
 The proceedings usually start with an informative (and highly
 entertaining) message from Steve Coya, the Executive Director of the
 IETF.  Each volume of contains the final (hindsight) agenda, an IETF
 overview, area and Working Group reports, and slides from the
 protocol and technical presentations.  The Working Group reports and
 presentations are sometimes incomplete, if the materials haven't been
 turned in to the Secretariat in time for publication.

Harris Informational [Page 16] RFC 3160 The Tao of IETF August 2001

 An attendee list is also included, and contains names, affiliations,
 work and fax phone numbers, and e-mail addresses as provided on the
 registration form.  For information about obtaining copies of the
 proceedings, see the Web listing at
 http://www.ietf.org/proceedings/directory.html.

2.11 Other General Things

 The IETF Secretariat, and IETFers in general, are very approachable.
 Never be afraid to approach someone and introduce yourself.  Also,
 don't be afraid to ask questions, especially when it comes to jargon
 and acronyms!
 Hallway conversations are very important.  A lot of very good work
 gets done by people who talk together between meetings and over
 lunches and dinners.  Every minute of the IETF can be considered work
 time (much to some people's dismay).
 A "bar BOF" is an unofficial get-together, usually in the late
 evening, during which a lot of work gets done over drinks.  Bar BOFs
 spring up in many different places around an IETF meeting, such as
 restaurants, coffee shops, and (if we are so lucky) pools.
 It's unwise to get between a hungry IETFer (and there isn't any other
 kind) and coffee break brownies and cookies, no matter how
 interesting a hallway conversation is.
 IETFers are fiercely independent.  It's safe to question opinions and
 offer alternatives, but don't expect an IETFer to follow orders.
 The IETF, and the plenary session in particular, are not places for
 vendors to try to sell their wares.  People can certainly answer
 questions about their company and its products, but bear in mind that
 the IETF is not a trade show.  This does not preclude people from
 recouping costs for IETF-related t-shirts, buttons and pocket
 protectors.
 There is always a "materials distribution table" near the
 registration desk.  This desk is used to make appropriate information
 available to the attendees (e.g., copies of something discussed in a
 Working Group session, descriptions of online IETF-related
 information, etc.).  Please check with the Secretariat before placing
 materials on the desk; the Secretariat has the right to remove
 material that they feel is not appropriate.

Harris Informational [Page 17] RFC 3160 The Tao of IETF August 2001

3.0 Working Groups

 The vast majority of the IETF's work is done in many "Working
 Groups;" at the time of this writing, there are about 115 different
 WGs.  (The term "Working Group" is often seen capitalized, but
 probably not for a very good reason.)  BCP 25, "IETF Working Group
 Guidelines and Procedures," is an excellent resource for anyone
 participating in WG discussions.
 A WG is really just a mailing list with a bit of adult supervision.
 You "join" the WG by subscribing to the mailing list; all mailing
 lists are open to anyone.  Some IETF WG mailing lists only let
 subscribers to the mailing list post to the mailing list, while
 others let anyone post.  Each Working Group has one or two chairs.
 More importantly, each WG has a charter that the WG is supposed to
 follow.  The charter states the scope of discussion for the Working
 Group, as well as its goals.  The WG's mailing list and face-to-face
 meetings are supposed to focus on just what is in the charter, and
 not to wander off on other "interesting" topics.  Of course, looking
 a bit outside the scope of the WG is occasionally useful, but the
 large majority of the discussion should be on the topics listed in
 the charter.  In fact, some WG charters actually specify what the WG
 will not do, particularly if there were some attractive but nebulous
 topics brought up during the drafting of the charter.  The list of
 all WG charters makes interesting reading for folks who want to know
 what the different Working Groups are supposed to be doing.

3.1 Working Group Chairs

 The role of the WG chairs is described in both BCP 11 and BCP 25.
 Basically, their job is to keep the discussion moving forward towards
 the milestones in the WG charter -- usually publication of one or
 more RFCs.  They are not meant to be taskmasters, but are responsible
 for assuring positive forward motion and preventing random wandering.
 As you can imagine, some Working Group chairs are much better at
 their jobs than others.  When a WG has fulfilled its charter, it is
 supposed to cease operations.  (Most WG mailing lists continue on
 after a WG is closed, still discussing the same topics as the Working
 Group did.)  In the IETF, it is a mark of success that the WG closes
 up because it fulfilled its charter.  This is one of the aspects of
 the IETF that newcomers who have experience with other standards
 bodies have a hard time understanding.  However, some WG chairs never
 manage to get their WG to finish, or keep adding new tasks to the
 charter so that the Working Group drags on for many years.  The
 output of these aging WGs is often not nearly as useful as the

Harris Informational [Page 18] RFC 3160 The Tao of IETF August 2001

 earlier products, and the messy results are sometimes called
 "degenerative Working Group syndrome."
 One important role of the chair is to decide which Internet Drafts
 get published as "official" Working Group drafts, and which don't.
 In practice, there is actually not much procedural difference between
 WG drafts and independent drafts; for example, many WG mailing lists
 also discuss independent drafts (at the discretion of the WG chair).
 Procedures for Internet Drafts are covered in much more detail later
 in this document.
 WG chairs are strongly advised to go to the new chairs' training
 lunch the first day of the IETF meeting.  If you're interested in
 what they hear there, take a look at the slides at
 http://www.ietf.org/wgchair/index.htm.

3.2 Getting Things Done in a Working Group

 One fact that confuses many novices is that the face-to-face WG
 meetings are much less important in the IETF than they are in most
 other organizations.  Any decision made at a face-to-face meeting
 must also gain consensus on the WG mailing list.  There are numerous
 examples of important decisions made in WG meetings that are later
 overturned on the mailing list, often because someone who couldn't
 attend the meeting pointed out a serious flaw in the logic used to
 come to the decision.
 Another aspect of Working Groups that confounds many people is the
 fact that there is no formal voting.  The general rule on disputed
 topics is that the Working Group has to come to "rough consensus,"
 meaning that a very large majority of those who care must agree.  The
 exact method of determining rough consensus varies from Working Group
 to Working Group.  The lack of voting has caused some very long
 delays for some proposals, but most IETF participants who have
 witnessed rough consensus after acrimonious debates feel that the
 delays often result in better protocols.  (And, if you think about
 it, how could you have "voting" in a group that anyone can join, and
 when it's impossible to count the participants?)

3.3 Preparing for Working Group Meetings

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

Harris Informational [Page 19] RFC 3160 The Tao of IETF August 2001

 It's up to the WG chair to set the meeting agenda, usually a few
 weeks in advance.  If you want something discussed at the meeting, be
 sure to let the chair know about it.  The agendas for all the WG
 meetings are available in advance (see
 http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the
 meeting number), but many WG chairs are lax (if not totally
 negligent) about turning them in.
 The Secretariat only schedules WG meetings a few weeks in advance,
 and the schedule often changes as little as a week before the first
 day.  If you are only coming for one WG meeting, you may have a hard
 time booking your flight with such little notice, particularly if the
 Working Group's meeting changes schedule.  Be sure to keep track of
 the current agenda so you can schedule flights and hotels.  But, when
 it comes down to it, you probably shouldn't be coming for just one WG
 meeting.  It's likely that your knowledge could be valuable in a few
 WGs, assuming that you've read the drafts and RFCs for those groups.
 If you're giving a presentation at a face-to-face meeting, you should
 probably come with a few slides prepared.  Projectors for laptop-
 based presentations are available in all the meeting rooms.  And
 here's a tip for your slides:  don't put your company's logo on every
 one, even though it's common practice outside the IETF.  The IETF
 frowns on this kind of corporate advertising, and most presenters
 don't even put their logo on their opening slide.  The IETF is about
 technical content, not company boosterism.

3.4 Working Group Mailing Lists

 As we mentioned earlier, the IETF announcement and discussion mailing
 lists are the central mailing lists for IETF activities.  However,
 there are many other mailing lists related to IETF work.  For
 example, every Working Group has its own discussion list.  In
 addition, there are some long-term technical debates that have been
 moved off of the IETF list onto lists created specifically for those
 topics.  It is highly recommended that everybody follow the
 discussions on the mailing lists of the Working Groups that they wish
 to attend.  The more work that is done on the mailing lists, the less
 work that will need to be done at the meeting, leaving time for cross
 pollination (i.e., attending Working Groups outside one's primary
 area of interest in order to broaden one's perspective).
 The mailing lists also provide a forum for those who wish to follow,
 or contribute to, the Working Groups' efforts, but can't attend the
 IETF meetings.

Harris Informational [Page 20] RFC 3160 The Tao of IETF August 2001

 Most IETF discussion lists use Majordomo and have a "-request"
 address which handles the administrative details of joining and
 leaving the list.  (See Section 1.3 for more information on
 Majordomo.)  It is generally frowned upon when such administrivia
 appears on the discussion mailing list.
 Most IETF discussion lists are archived.  That is, all of the
 messages sent to the list are automatically stored on a host for
 anonymous FTP access.  Many such archives are listed online at
 ftp://ftp.ietf.org/ietf-mail-archive/.  If you don't find the list
 you're looking for, send a message to the list's "-request" address
 (not to the list itself!).

3.5 Interim Working Group Meetings

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

4. BOFs

 In order to form a Working Group, you need a charter and someone who
 is able to be chair.  In order to get those things, you need to get
 people interested so that they can help focus the charter and
 convince an Area Director that the project is worthwhile.  A face-
 to-face meeting is useful for this.  In fact, very few WGs get
 started by an Area Director; most start after a face-to-face BOF
 because attendees have expressed interest in the topic.
 A BOF meeting has to be approved by the Area Director in the relevant
 area before it can be scheduled.  If you think you really need a new
 WG, approach an AD informally with your proposal and see what they
 think.  The next step is to request a meeting slot at the next face-
 to-face meeting.  Of course, you don't need to wait for that meeting
 to get some work done, such as setting up a mailing list and starting
 to discuss a charter.
 BOF meetings have a very different tone than WG meetings.  The
 purpose of a BOF is to make sure that a good charter with good
 milestones can be created, and that there are enough people willing
 to do the work needed in order to create standards.  Some BOFs have
 Internet Drafts already in process, while others start from scratch.

Harris Informational [Page 21] RFC 3160 The Tao of IETF August 2001

 An advantage of having a draft before the BOF is to help focus the
 discussion.  On the other hand, having a draft might tend to limit
 what the other folks in the BOF want to do in the charter.  It's
 important to remember that most BOFs are held in order to get support
 for an eventual Working Group, not to get support for a particular
 document.
 Many BOFs don't turn into WGs for a variety of reasons.  A common
 problem is that not enough people can agree on a focus for the work.
 Another typical reason is that the work wouldn't end up being a
 standard -- if, for example, the document authors don't really want
 to relinquish change control to a WG.  (We'll discuss change control
 later in this document.)  Only two meetings of a BOF can be scheduled
 on a particular subject; either a WG has to form, or the topic should
 be dropped.

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

  1. —————————————-

If you're new to the IETF and this is the only reference you plan to

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

6. RFCs and Internet Drafts

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

6.1 Getting a Standard Published

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

Harris Informational [Page 22] RFC 3160 The Tao of IETF August 2001

 Every IETF standard is published as an RFC (a "Request For Comments,"
 but everyone just calls them RFCs), and every RFC starts out as an
 Internet Draft (often called an "I-D").  The basic steps for getting
 something published as an IETF standard are:
    1. Publish the document as an Internet Draft
    2. Receive comments on the draft
    3. Edit your draft based on the comments
    4. Repeat steps 1 through 3 a few times
    5. Ask an Area Director to take the draft to the IESG (if it's an
       individual submission).  If the draft is an official Working
       Group product, the WG chair asks the AD to take it to the IESG.
    6. Make any changes deemed necessary by the IESG (this might
       include giving up on becoming a standard)
    7. Wait for the document to be published by the RFC Editor
 A much more complete explanation of these steps is contained in BCP
 9, "The Internet Standards Process."  Anyone who writes a draft that
 they hope will become an IETF standard must read BCP 9 so that they
 can follow the path of their document through the process.  BCP 9
 goes into great detail on a topic that is very often misunderstood,
 even by seasoned IETF participants:  different types of RFCs go
 through different processes and have different rankings.  There are
 six kinds of RFCs:
  1. Proposed standards
  2. Draft standards
  3. Internet standards (sometimes called "full standards")
  4. Experimental protocols
  5. Informational documents
  6. Historic standards
 Only the first three (proposed, draft, and full) are standards within
 the IETF.  A good summary of this can be found in the aptly titled
 RFC 1796, "Not All RFCs are Standards."
 There are also three sub-series of RFCs, known as FYIs, BCPs, and
 STDs.  The For Your Information RFC sub-series was created to
 document overviews and topics which are introductory or appeal to a
 broad audience.  Frequently, FYIs are created by groups within the
 IETF User Services Area.  Best Current Practice documents describe
 the application of various technologies in the Internet.  The STD RFC
 sub-series was created to identify RFCs that do in fact specify
 Internet standards.  Some STDs are actually sets of more than one
 RFC, and the "standard" designation applies to the whole set of
 documents.

Harris Informational [Page 23] RFC 3160 The Tao of IETF August 2001

6.2 Letting Go Gracefully

 The biggest reason some people do not want their documents put on the
 IETF standards track is that they must give up change control of the
 protocol.  That is, as soon as you propose that your protocol become
 an IETF standard, you must fully relinquish control of the protocol.
 If there is general agreement, parts of the protocol can be
 completely changed, whole sections can be ripped out, new things can
 be added, and the name can be changed.
 Some authors find it very hard to give up control of their pet
 protocol.  If you are one of those people, don't even think about
 trying to get your protocol to become an IETF standard.  On the other
 hand, if your goal is the best standard possible with the widest
 implementation, then you might find the IETF process to your liking.
 Incidentally, the change control on Internet standards doesn't end
 when the protocol is put on the standards track.  The protocol itself
 can be changed later for a number of reasons, the most common of
 which is that implementors discover a problem as they implement the
 standard.  These later changes are also under the control of the
 IETF, not the editors of the standards document.
 IETF standards exist so that people will use them to write Internet
 programs that interoperate.  They don't exist to document the
 (possibly wonderful) ideas of their authors, nor do they exist so
 that a company can say "we have an IETF standard."  If a standards-
 track RFC only has one implementation (whereas two are required for
 it to advance on the standards track), it was probably a mistake to
 put it on the standards track in the first place.

6.3 Internet Drafts

 First things first.  Every document that ends up in the RFC
 repository starts life as an Internet Draft.  Internet Drafts are
 tentative documents -- they're meant for readers to comment on, so
 authors can mull over those comments and decide which ones to
 incorporate in the draft.  In order to remind folks of their
 tentativeness, Internet Drafts are automatically removed from the
 online directories after six months.  They are most definitely not
 standards or even specifications.  As BCP 9 says:
    An Internet Draft is NOT a means of "publishing" a specification;
    specifications are published through the RFC mechanism ...
    Internet Drafts have no formal status, and are subject to change
    or removal at any time.  Under no circumstances should an Internet
    Draft be referenced by any paper, report, or Request-for-Proposal,
    nor should a vendor claim compliance with an Internet Draft.

Harris Informational [Page 24] RFC 3160 The Tao of IETF August 2001

 You can always tell a person who doesn't understand the IETF (or is
 intentionally trying to fool people) when they brag about having
 published an Internet Draft; it takes no significant effort.
 An I-D should have approximately the same format as an RFC.  Contrary
 to many people's beliefs, an I-D does not need to look exactly like
 an RFC, but if you can use the same formatting procedures used by the
 RFC Editor when you create your I-Ds, it will simplify the RFC
 Editor's work when your draft is published as an RFC.  RFC 2223,
 "Instructions to RFC Authors," describes the nroff formatting used by
 the RFC Editor.
 An Internet Draft can be either a Working Group draft or an
 individual submission.  Working Group drafts are usually reviewed by
 the chair before being accepted as a WG item.

6.3.1 Recommended Reading for Writers

 Before you create the first draft of your Internet Draft, you should
 read four documents:
  1. More important than just explaining formatting, RFC 2223 also

explains what needs to be in an Internet Draft before it can

      become an RFC.  This document describes all the sections and
      notices that will need to be in your document, and it's good to
      have them there from the beginning so that readers aren't
      surprised when you put them in later versions.
  1. BCP 22, "Guide for Internet Standards Writers," provides tips

that will help you write a standard that leads to

      interoperability.  For instance, it explains how to choose the
      right number of protocol options, how to respond to out-of-spec
      behavior, and how to show state diagrams.
  1. 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.
  1. When you think you are finished with the draft process and are

ready to request that the draft become an RFC, you should

      definitely read "Considerations for Internet Drafts,"
      http://www.ietf.org/ID-nits.html, a list of common "nits" that
      have been known to stop documents in the IESG.  In fact, you
      should probably read that document well before you are finished,
      so that you don't have to make a bunch of last-minute changes.

Harris Informational [Page 25] RFC 3160 The Tao of IETF August 2001

6.3.2 Filenames and Other Matters

 When you're ready to turn in your Internet Draft, send it to the
 Internet Drafts editor at internet-drafts@ietf.org.  There is a real
 person at the other end of this mail address -- their job is to make
 sure you've included the minimum items you need for the Internet
 Draft to be published.  When you submit the first version of the
 draft, the draft editor supplies the filename for the draft.  If the
 draft is an official Working Group product, the name will start with
 "draft-ietf-" followed by the designation of the WG, followed by a
 descriptive word or two, followed by "00.txt".
 For example, a draft in the S/MIME WG about creating keys might be
 named "draft-ietf-smime-keying-00.txt".  If it's not the product of a
 Working Group, the name will start with "draft-" and the last name of
 one of the authors followed by a descriptive word or two, followed by
 "00.txt".  For example, a draft that someone named Smith wrote might
 be named "draft-smith-keying-00.txt".  If a draft is an individual
 submission but relates to a particular working group, the author
 sometimes follows their name with the name of the working group, such
 as "draft-smith-smime-keying-00.txt".  You are welcome to suggest
 names; however, it is up to the Internet Drafts editor (and, if it is
 an official WG draft, the WG chair) to come up with the filename.
 After the first edition of a draft, the number in the filename is
 incremented; for instance, the second edition of the S/MIME draft
 named above would be "draft-ietf-smime-keying-01.txt".  Note that
 there are cases where the filename changes after the first version,
 such as when a personal effort is pulled into a Working Group.

6.4 Standards-Track RFCs

 The procedure for creating and advancing a standard is described in
 BCP 9.  After an Internet Draft has been sufficiently discussed and
 there is rough consensus that what it says would be a useful
 standard, it is presented to the IESG for consideration.  If the
 draft is an official WG draft, the WG chair sends it to the
 appropriate Area Director after it has gone through Working Group
 last call.  If the draft is an individual submission, the draft's
 author or editor submits it to the appropriate Area Director.  BCP 9
 also describes the appeals process for people who feel that a Working
 Group chair, an AD, or the IESG has made the wrong decision in
 considering the creation or advancement of a standard.
 After it is submitted to the IESG, the IESG announces an IETF-wide
 last call.  This helps get the attention of people who weren't
 following the progress of the draft, and can sometimes cause further
 changes to the draft.  It is also a time when people in the WG who

Harris Informational [Page 26] RFC 3160 The Tao of IETF August 2001

 feel that they weren't heard can make their comments to everyone.
 The IETF last call is two weeks for drafts coming from WGs and four
 weeks for individual submissions.
 If the IESG approves the draft to become an Internet Standard, they
 ask the RFC Editor to publish it as a Proposed Standard.  After it
 has been a Proposed Standard for at least six months, the RFC's
 author (or the appropriate WG chair) can ask for it to become a Draft
 Standard.  Before that happens, however, someone needs to convince
 the appropriate Area Director that there are at least two
 independent, interoperable implementations of each part of the
 standard.  This is a good test of the usefulness of the standard as a
 whole, as well as an excellent way to check if the standard was
 really readable.
 A few things typically happen at this point.  First, it's common to
 find that some of the specifications in the standard need to be
 reworded because one implementor thought they meant one thing while
 another implementor thought they meant something else.  Another
 common occurrence is that none of the implementations actually tried
 to implement a few of the features of the standard; these features
 get removed not just because no one tested them, but also because
 they weren't needed.
 Don't be surprised if a particular standard doesn't progress from
 Proposed to Draft.  In fact, most of the standards in common use are
 Proposed Standards and never move forward.  This may be because no
 one took the time to try to get them to Draft, or some of the
 normative references in the standard are still at Proposed Standard,
 or it may be that everyone found more important things to do.
 A few years after a document has been a Draft Standard, it can become
 an Internet Standard, also known as "full standard."  This doesn't
 happen often, and is usually reserved for protocols that are
 absolutely required for the Internet to function.  The IESG goes over
 the document with a fine-tooth comb before making a Draft Standard an
 Internet Standard.

6.4.1 Telling It Like It Is – Using MUST and SHOULD and MAY

 Writing specifications that get implemented the way you want is a bit
 of an art.  You can keep the specification very short, with just a
 list of requirements, but that tends to cause implementors to take
 too much leeway.  If you instead make the specification very wordy
 with lots of suggestions, implementors tend to miss the requirements
 (and often disagree with your suggestions anyway).  An optimal
 specification is somewhere in between.

Harris Informational [Page 27] RFC 3160 The Tao of IETF August 2001

 One way to make it more likely that developers will create
 interoperable implementations of standards is to be clear about
 what's being mandated in a specification.  Early RFCs used all kinds
 of expressions to explain what was needed, so implementors didn't
 always know which parts were suggestions and which were requirements.
 As a result, standards writers in the IETF generally agreed to limit
 their wording to a few specific words with a few specific meanings.
 RFC 1123, "Requirements for Internet Hosts -- Application and
 Support," written way back in 1989, had a short list of words that
 had appeared to be useful, namely "must", "should", and "may".  These
 definitions were updated and further refined in BCP 14, "Key words
 for use in RFCs to Indicate Requirement Levels," which is widely
 referenced in current Internet standards.  BCP 14 also specifically
 defines "must not" and "should not", and lists a few synonyms for the
 words defined.
 In a standard, in order to make it clear that you're using the
 definitions from BCP 14, you should do two things.  First, refer to
 BCP 14 (although most people refer to it as RFC 2119, because that's
 what BCP 14 tells you to do), so that the reader knows how you're
 defining your words.  Second, you should point out which instances of
 the words you are using come from BCP 14.  The accepted practice for
 this is to capitalize the words.  That is why you see "MUST" and
 "SHOULD" capitalized in IETF standards.
 BCP 14 is a short document, and should be read by everyone who is
 reading or writing IETF standards.  Although the definitions of
 "must" and "must not" are fairly clear, the definitions of "should"
 and "should not" cause a great deal of discussion in many WGs.  When
 reviewing an Internet Draft, the question is often raised, "should
 that sentence have a MUST or a SHOULD in it?"  This is, indeed, a
 very good question, because specifications shouldn't have gratuitous
 MUSTs, but also should not have SHOULDs where a MUST is needed for
 interoperability.  This goes to the crux of the question of over-
 specifying and under-specifying requirements in standards.

6.4.2 Normative References in Standards

 One aspect of writing IETF standards that trips up many novices (and
 quite a few long-time IETF folk) is the rule about how to make
 "normative references" to non-IETF documents or to other RFCs in a
 standard.  A normative reference is a reference to a document that
 must be followed in order to implement the standard.  A non-normative
 reference is one that is helpful to an implementor but is not needed.
 As we noted above, a "MUST" specification would certainly be
 normative, so any reference needed to implement the "MUST" would be
 normative.  A "SHOULD" or "MAY" specification is not necessarily

Harris Informational [Page 28] RFC 3160 The Tao of IETF August 2001

 normative, but it could be normative based on what is being required.
 There is definitely room for debate here!
 An IETF standard may make a normative reference to any other
 standards-track RFC that is at the same standards level or higher, or
 to any "open standard" that has been developed outside the IETF.  The
 "same level or higher" rule means that before a standard can move
 from Proposed to Draft, all of the RFCs for which there is a
 normative reference must also be at Draft or Internet Standard.  This
 rule gives implementors assurance that everything in a Draft Standard
 or Internet Standard is quite stable, even the things referenced
 outside the standard.  This can also delay the publication of the
 Draft or Internet Standard by many months (sometimes even years)
 while the other documents catch up.
 There is no hard and fast rule about what is an "open standard," but
 generally this means a stable standard that anyone can get a copy of
 (although they might have to pay for it) and that was made by a
 generally recognized standards group.  If the external standard
 changes, you have to reference the particular instantiation of that
 standard in your specification, as with a designation of the date of
 the standard.  Some external standards bodies don't make old
 standards available, which is a problem for IETF standards that need
 to be used in the future.  When in doubt, a draft author should ask
 the WG chair or appropriate Area Director if a particular external
 standard can be used in an IETF standard.

6.4.3 IANA Considerations

 More and more IETF standards require the registration of various
 protocol parameters, such as named options in the protocol.  As we
 noted in Section 1.2.4, the main registry for all IETF standards has
 long been IANA.  Because of the large and diverse kinds of registries
 that standards require, IANA needs to have specific information about
 how to register parameters, what not to register, who (if anyone)
 will decide what is to be registered, and so on.
 Anyone writing an Internet standard that may need an IANA registry
 needs to read BCP 26, "Guidelines for Writing an IANA Considerations
 Section in RFCs," which describes how RFC authors should properly ask
 for IANA to start or take over a registry.  IANA also maintains
 registries that were started long before BCP 26 was produced.

6.4.4 Security Considerations

 One thing that's required in every RFC is a "Security Considerations"
 section.  This section should describe any known vulnerabilities of
 the protocol, possible threats, and mechanisms or strategies to

Harris Informational [Page 29] RFC 3160 The Tao of IETF August 2001

 address them.  Don't gloss over this section -- in particular, don't
 say "here's our protocol, if you want security, just use IPSEC".
 This won't do at all, because it doesn't answer the question of how
 IPSEC interacts with your protocol, and vice versa.  Be sure to check
 with your Working Group chair if you're not sure how to handle this
 section in your draft.

6.4.5 Patents in IETF Standards

 The problems of intellectual property have cropped up more and more
 often in the past few years, particularly with respect to patents.
 The goal of the IETF is to have its standards widely used and
 validated in the marketplace.  If creating a product that uses a
 standard requires getting a license for a patent, people are less
 likely to implement the standard.  Not surprisingly, then, the
 general rule has been "use good non-patented technology where
 possible."
 Of course, this isn't always possible.  Sometimes patents appear
 after a standard has been established.  Sometimes there's a patent on
 something that is so valuable that there isn't a non-patented
 equivalent.  Sometimes, the patent holder is generous and promises to
 give all implementors of a standard a royalty-free license to the
 patent, thereby making it almost as easy to implement as it would
 have been if no patent existed.
 The IETF's methods for dealing with patents in standards are a
 subject of much debate.  You can read about the official rules in BCP
 9, but you should assume that the application of those rules is
 flexible and depends on the type of patent, the patent holder, and
 the availability of alternate technologies that are not encumbered by
 patents.
 Patent holders who freely allow their patents to be used by people
 implementing IETF standards often get a great deal of good will from
 the folks in the IETF.  Such generosity is more common than you might
 think.  For example, RFC 1822 is a license from IBM for one of its
 security patents, and the security community has responded very
 favorably to IBM for this (whereas a number of other companies have
 made themselves pariahs for their intractability on their security
 patents).
 If you are writing an Internet Draft and you know of a patent that
 applies to the technology you're writing about, don't list the patent
 in the document.  Instead, send a note to the IETF Secretariat
 (ietf-secretariat@ietf.org) about the patent or other intellectual
 property rights.  The note will be published on the IETF IPR web page
 (http://www.ietf.org/ipr.html).  Intellectual property rights aren't

Harris Informational [Page 30] RFC 3160 The Tao of IETF August 2001

 mentioned in RFCs because RFCs never change after they are published,
 but knowledge of IPR can change at any time.  Therefore, an IPR list
 in a RFC could be incomplete and mislead the reader.  BCP 9 provides
 specific text that should be added to RFCs where the author knows of
 IPR issues.

6.5 Informational and Experimental RFCs

 As we noted earlier, not all RFCs are standards.  In fact, plenty of
 important RFCs are not on the standards track at all.  Currently,
 there are two designations for RFCs that are not meant to be
 standards:  Informational, like the Tao, and Experimental.  (There is
 actually a third designation, Historical, but that is reserved for
 documents that were on the standards track and have been removed due
 to lack of current use, or that more recent thinking indicates the
 technology is actually harmful to the Internet.)
 The role of Informational RFCs is often debated in the IETF.  Many
 people like having them, particularly for specifications that were
 created outside the IETF but are referenced by IETF documents.  They
 are also useful for specifications that are the precursors for work
 being done by IETF Working Groups.  On the other hand, some people
 refer to Informational RFCs as "standards" even though the RFCs are
 not standards, usually to fool the gullible public about something
 that the person is selling or supporting.  When this happens, the
 debate about Informational RFCs is renewed.
 Experimental RFCs are for specifications that may be interesting, but
 for which it is unclear if there will be much interest in
 implementing them.  That is, a specification might solve a problem,
 but if it is not clear many people think that the problem is
 important, or think that they will bother fixing the problem with the
 specification, the specification might be labeled an Experimental
 RFC.  If, later, the specification becomes popular, it can be re-
 issued as a standards-track RFC.  Experimental RFCs are also used to
 get people to experiment with a technology that looks like it might
 be standards track material, but for which there are still unanswered
 questions.

7. How to Contribute to the IETF – What You Can Do

 Read --        Review the Internet Drafts in your area of expertise,
                and comment on them in the Working Groups.
                Participate in the discussion in a friendly, helpful
                fashion, with the goal being the best Internet
                standards possible.  Listen much more than you speak.

Harris Informational [Page 31] RFC 3160 The Tao of IETF August 2001

 Implement --   Write programs that use the current Internet
                standards.  The standards aren't worth much unless
                they are available to Internet users.  Implement even
                the "minor" standards, since they will become less
                minor if they appear in more software.  Report any
                problems you find with the standards to the
                appropriate Working Group so that the standard can be
                clarified in later revisions.  One of the oft-quoted
                tenets of the IETF is "running code wins," so you can
                help support the standards you want to become more
                widespread by creating more running code.
 Write --       Edit or co-author Internet Drafts in your area of
                expertise.  Do this for the benefit of the Internet
                community, not to get your name (or, even worse, your
                company's name) on a document.  Draft authors are
                subject to all kinds of technical (and sometimes
                personal) criticism; receive it with equanimity and
                use it to improve your draft in order to produce the
                best and most interoperable standard.

7.1 What Your Company Can Do

 Share --       Avoid proprietary standards.  If you are an
                implementor, exhibit a strong preference for IETF
                standards.  If the IETF standards aren't as good as
                the proprietary standards, work to make the IETF
                standards better.  If you're a purchaser, avoid
                products that use proprietary standards that compete
                with the open standards of the IETF, and tell the
                companies you buy from that you are doing so.
 Open Up --     If your company controls a patent that is used in an
                IETF standard, convince them to make the patent
                available at no cost to everyone who is implementing
                the standard.  In the past few years, patents have
                caused a lot of serious problems for Internet
                standards because they prevent some companies from
                being able to freely implement the standards.
                Fortunately, many companies have generously offered
                unlimited licenses for particular patents in order to
                help the IETF standards flourish.  These companies are
                usually rewarded with positive publicity for the fact
                that they are not as greedy or short-sighted as other
                patent-holders.

Harris Informational [Page 32] RFC 3160 The Tao of IETF August 2001

 Join --        Become a member of ISOC.  More importantly, urge any
                company that has benefited from the Internet to become
                a corporate member of ISOC, since this has the
                greatest financial benefit for the group.  It will, of
                course, also benefit the Internet as a whole.

8. IETF and the Outside World

8.1 IETF and Other Standards Groups

 As much as many IETF participants would like to think otherwise, the
 IETF does not exist in a standards vacuum.  There are many (perhaps
 too many) other standards organizations whose decisions affect the
 Internet.  There are also a fair number of standards bodies who
 ignored the Internet for a long time and now want to get a piece of
 the action.
 In general, the IETF tries to have cordial relationships with other
 significant standards bodies.  This isn't always easy, since many
 other bodies have very different structures than the IETF, and the
 IETF is mostly run by volunteers who would probably prefer to write
 standards rather than meet with representatives from other bodies.
 Even so, some other standards bodies make a great effort to interact
 well with the IETF despite the obvious cultural differences.
 At the time of this writing, the IESG has some liaisons with large
 standards bodies, including the ITU (International Telecommunication
 Union), the W3C, the Unicode Consortium, the ATM Forum, and ISO-
 IEC/JTC1 (The Joint Technical Committee of the International
 Organization for Standardization and International Electrotechnical
 Commission).  The list of IETF liaisons, www.ietf.org/ietf/1iesg-
 liaisons.txt, shows that there are many different liaisons to ISO-
 IEC/JTC1 subcommittees.

8.2 Press Coverage of the IETF

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

Harris Informational [Page 33] RFC 3160 The Tao of IETF August 2001

 Major press errors fall into two categories: saying that the IETF is
 considering something when in fact there is just an Internet Draft in
 a Working Group, and saying that the IETF approved something when all
 that happened was that an Informational RFC was published.  In both
 cases, the press is not fully to blame for the problem, since they
 are usually alerted to the story by a company trying to get publicity
 for a protocol that they developed or at least support.  Of course, a
 bit of research by the reporter would probably get them in contact
 with someone who could straighten them out, such as a WG chair or an
 Area Director.  The official press contact for the IETF is the IETF
 Secretariat.
 The fact that those reporters who've gotten it wrong once come back
 to IETF meetings shows that it is possible to get it right
 eventually.  However, IETF meetings are definitely not for reporters
 who are naive about the IETF process (although if you are a reporter
 the fact that you are reading this document is a very good sign!).
 Further, if you think that you'll get a hot story from attending an
 IETF meeting, you are likely to be disappointed.
 Considering all this, it's not surprising that some IETFers would
 prefer to have the press stay as far away from meetings as possible.
 Having a bit of press publicity for protocols that are almost near
 completion and will become significant in the industry in the next
 year can be a good thing.  However, it is the rare reporter who can
 resist over-hyping a nascent protocol as the next savior for the
 Internet.  Such stories do much more harm than good, both for the
 readers of the article and for the IETF.
 The main reason why a reporter might want to attend an IETF meeting
 is not to cover hot technologies (since that can be done in the
 comfort of your office by reading the mailing lists), but to meet
 people face to face.  Unfortunately, the most interesting people are
 the ones who are also the busiest during the IETF meeting, and some
 folks have a tendency to run away when they see a press badge.
 However, IETF meetings are excellent places to meet and speak with
 document authors and Working Group chairs; this can be quite valuable
 for reporters who are covering the progress of protocols.
 Reporters who want to find out about "what the IETF is doing" on a
 particular topic would be well-advised to talk to more than one
 person who is active on that topic in the IETF, and should probably
 try to talk to the WG chair in any case.  It's impossible to
 determine what will happen with a draft by looking at the draft or
 talking to the draft's author.  Fortunately, all WGs have archives
 that a reporter can look through for recent indications about what
 the progress of a draft is; unfortunately, few reporters have the
 time or inclination to do this kind of research.  Because the IETF

Harris Informational [Page 34] RFC 3160 The Tao of IETF August 2001

 doesn't have a press liaison, a magazine or newspaper that runs a
 story with errors won't hear directly from the IETF and therefore
 often won't know what they did wrong, so they might easily do it
 again later.

9. References

9.1 Tao

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

9.2 Useful E-mail Addresses

 agenda@ietf.org              Requests for agenda slots at IETF
                                   meetings
 ietf-info@ietf.org           General questions about the IETF
 ietf-registrar@ietf.org      Questions about registration, meeting
                                   locations, and fees
 ietf-request@ietf.org        Requests to join/leave IETF lists
 ietf-secretariat@ietf.org    Questions for the Secretariat
 ietf-web@ietf.org            Web questions/comments
 internet-drafts@ietf.org     Internet Draft submissions and queries
 minutes@ietf.org             Where to send Working Group minutes
 proceedings@ietf.org         IETF Proceedings Coordinator
 iana@iana.org                Internet Assigned Numbers Authority
 rfc-ed@rfc-editor.org        RFC Editor

9.3 Useful Documents and Files

 The IETF web site, http://www.ietf.org, is the best source for
 information about meetings, Working Groups, Internet Drafts, RFCs,
 IETF e-mail addresses, and much more.  Click on "Additional
 Information" to find a variety of helpful links.  Internet Drafts and
 other documents are also available in the "ietf" directory on
 anonymous FTP sites worldwide.  For a listing of these sites, see:
    http://www.ietf.org/shadow.html
 Check the IESG web pages, http://www.ietf.org/iesg.html, to find
 up-to-date information about drafts processed, RFCs published, and
 documents in Last Call, as well as the monthly IETF status reports.

Harris Informational [Page 35] RFC 3160 The Tao of IETF August 2001

9.4 Acronyms and Abbreviations Used in the Tao

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

9.5 Documents Cited in the Tao

 BCP 9     "The Internet Standards Process"
 BCP 10    "IAB and IESG Selection, Confirmation, and Recall Process:
            Operation of the Nominating and Recall Committees"
 BCP 11    "The Organizations Involved in the IETF Standards Process"
 BCP 14    "Key words for use in RFCs to Indicate Requirement Levels"
 BCP 22    "Guide for Internet Standards Writers"
 BCP 25    "IETF Working Group Guidelines and Procedures"
 BCP 26    "Guidelines for Writing an IANA Considerations Section
            in RFCs"
 RFC 1123  "Requirements for Internet Hosts -- Application and
            Support"
 RFC 1796  "Not All RFCs are Standards"
 RFC 2223  "Instructions to RFC Authors"

Harris Informational [Page 36] RFC 3160 The Tao of IETF August 2001

 "Considerations for Internet Drafts,"
    http://www.ietf.org/ID-nits.html
 "Guidelines to Authors of Internet-Drafts,"
    ftp://ftp.ietf.org/ietf/1id-guidelines.txt

Security Considerations

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

Editor's Address

 Susan Harris
 Merit Network, Inc.
 4251 Plymouth Road, Suite 2000
 Ann Arbor, MI  48105
 EMail: srh@merit.edu

Harris Informational [Page 37] RFC 3160 The Tao of IETF August 2001

Full Copyright Statement

 Copyright (C) The Internet Society (2001).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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

Harris Informational [Page 38]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3160.txt · Last modified: 2001/08/30 15:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki