diff options
Diffstat (limited to 'doc/rfc/rfc3160.txt')
| -rw-r--r-- | doc/rfc/rfc3160.txt | 2131 |
1 files changed, 2131 insertions, 0 deletions
diff --git a/doc/rfc/rfc3160.txt b/doc/rfc/rfc3160.txt new file mode 100644 index 0000000..5145046 --- /dev/null +++ b/doc/rfc/rfc3160.txt @@ -0,0 +1,2131 @@ + + + + + + +Network Working Group S. Harris +Request for Comments: 3160 Merit Network +FYI: 17 August 2001 +Obsoletes: 1718 +Category: Informational + + + The Tao of IETF - A Novice's Guide to the Internet Engineering + Task Force + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document describes the inner workings of IETF meetings and + Working Groups, discusses organizations related to the IETF, and + introduces the standards process. + +Table of Contents + + Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. What Is the IETF? . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Humble Beginnings. . . . . . . . . . . . . . . . . . . . 5 + 1.2 The Hierarchy . . . . . . . . . . . . . . . . . . . . . 5 + 1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2.2 IESG . . . . . . . . . . . . . . . . . . . . . . 6 + 1.2.3 IAB. . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . . 8 + 1.2.5 RFC Editor . . . . . . . . . . . . . . . . . . . . 8 + 1.2.6 IETF Secretariat . . . . . . . . . . . . . . . . . 9 + 1.3 IETF Mailing Lists. . . . . . . . . . . . . . . . . . . 9 + 2. IETF Meetings . . . . . . . . . . . . . . . . . . . . . . 10 + 2.1 Registration . . . . . . . . . . . . . . . . . . . . . 11 + 2.2 Newcomers' Orientation. . . . . . . . . . . . . . . . . 12 + 2.3 Dress Code. . . . . . . . . . . . . . . . . . . . . . . 12 + 2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . . 13 + 2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . . 13 + 2.6 Meals and Other Delights. . . . . . . . . . . . . . . . 14 + 2.7 Social Event. . . . . . . . . . . . . . . . . . . . . . 14 + + + +Harris Informational [Page 1] + +RFC 3160 The Tao of IETF August 2001 + + + 2.8 Agenda. . . . . . . . . . . . . . . . . . . . . . . . . 14 + 2.9 Where Do I Fit In?. . . . . . . . . . . . . . . . . . . 15 + 2.9.1 IS Managers. . . . . . . . . . . . . . . . . . . 15 + 2.9.2 Network Operators and ISPs . . . . . . . . . . . 15 + 2.9.3 Networking Hardware and Software Vendors . . . . 15 + 2.9.4 Academics . . . . . . . . . . . . . . . . . . . 16 + 2.9.5 Computer Trade Press . . . . . . . . . . . . . . 16 + 2.10 Proceedings. . . . . . . . . . . . . . . . . . . . . . 16 + 2.11 Other General Things . . . . . . . . . . . . . . . . . 17 + 3. Working Groups. . . . . . . . . . . . . . . . . . . . . . . 18 + 3.1 Working Group Chairs . . . . . . . . . . . . . . . . . .18 + 3.2 Getting Things Done in a Working Group. . . . . . . . . 19 + 3.3 Preparing for Working Group Meetings . . . . . . . . 19 + 3.4 Working Group Mailing Lists . . . . . . . . . . . . . 20 + 3.5 Interim Working Group Meetings . . . . . . . . . . . . 21 + 4. BOFs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5. New to the IETF? STOP HERE! (Temporarily). . . . . . . . . 22 + 6. RFCs and Internet Drafts . . . . . . . . . . . . . . . . . 22 + 6.1 Getting a Standard Published . . . . . . . . . . . . . 22 + 6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . . 24 + 6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . . 24 + 6.3.1 Recommended Reading for Writers . . . . . . . . . 25 + 6.3.2 Filenames and Other Matters . . . . . . . . . . . 26 + 6.4 Standards-Track RFCs . . . . . . . . . . . . . . . . . 26 + 6.4.1 Telling It Like It Is -- Using MUST and + SHOULD and MAY. . . . . . . . . . . . . . . . . . 27 + 6.4.2 Normative References in Standards . . . . . . . . 28 + 6.4.3 IANA Considerations . . . . . . . . . . . . . . . 29 + 6.4.4 Security Considerations . . . . . . . . . . . . . 29 + 6.4.5 Patents in IETF Standards . . . . . . . . . . . . 30 + 6.5 Informational and Experimental RFCs . . . . . . . . . . 31 + 7. How to Contribute to the IETF -- What You Can Do . . . . . . 31 + 7.1 What Your Company Can Do . . . . . . . . . . . . . . . 32 + 8. IETF and the Outside World . . . . . . . . . . . . . . . . . 33 + 8.1 IETF and Other Standards Groups . . . . . . . . . . . . 33 + 8.2 Press Coverage of the IETF. . . . . . . . . . . . . . . 33 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . . 35 + 9.3 Useful Documents and Files. . . . . . . . . . . . . . . 35 + 9.4 Acronyms and Abbreviations Used in the Tao . . . . . . 36 + 9.5 Documents Cited in the Tao . . . . . . . . . . . . . . 36 + Security Considerations . . . . . . . . . . . . . . . . . . . . 37 + Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 37 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 38 + + + + + + +Harris Informational [Page 2] + +RFC 3160 The Tao of IETF August 2001 + + +Introduction + + Over the last several years, attendance at Internet Engineering Task + Force (IETF) face-to-face meetings has grown phenomenally. Many of + the attendees are new to the IETF at each meeting, and many of those + go on to become regular attendees. When the meetings were smaller, + it was relatively easy for a newcomer to get into the swing of + things. Today, however, a newcomer meets many more new people, some + previously known only as the authors of documents or thought- + provoking e-mail messages. + + This document describes many aspects of the IETF, with the goal of + explaining to newcomers how the IETF works. This will give them a + warm, fuzzy feeling and enable them to make the meeting and the + Working Group discussions more productive for everyone. + + Of course, it's true that many IETF participants don't go to the + face-to-face meetings at all. Instead, they're active on the mailing + list of various IETF Working Groups. Since the inner workings of + Working Groups can be hard for newcomers to understand, this FYI + provides the mundane bits of information that newcomers will need in + order to become active participants. + + Many types of IETF documentation are mentioned in the Tao, from BCPs + to RFCs and FYIs. (BCPs make recommendations for Best Current + Practices in the Internet; RFCs are the IETF's main technical + documentation series, politely known as "Requests for Comments;" and + FYIs provide topical and technical overviews that are introductory or + appeal to a broad audience. See Section 6 for more information.) + + The acronyms and abbreviations used in this document are usually + expanded in place, and are explained fully in Section 9. + +Acknowledgements + + The original version of this document, published in 1994, was written + by Gary Malkin. His knowledge of the IETF, insights, and unmatched + writing style set the standard for this later revision, and his + contributions to the current draft are also much appreciated. Paul + Hoffman wrote significant portions of this revision and provided + encouragement, expertise, and much-needed guidance. Other + contributors include Scott Bradner, Michael Patton, Donald E. + Eastlake III, the IETF Secretariat, and members of the User Services + Working Group. + + + + + + + +Harris Informational [Page 3] + +RFC 3160 The Tao of IETF August 2001 + + +1. What Is the IETF? + + The Internet Engineering Task Force is a loosely self-organized group + of people who contribute to the engineering and evolution of Internet + technologies. It is the principal body engaged in the development of + new Internet standard specifications. The IETF is unusual in that it + exists as a collection of happenings, but is not a corporation and + has no board of directors, no members, and no dues. + + Its mission includes: + + - Identifying, and proposing solutions to, pressing operational and + technical problems in the Internet; + + - Specifying the development or usage of protocols and the near-term + architecture to solve such technical problems for the Internet; + + - Making recommendations to the Internet Engineering Steering Group + (IESG) regarding the standardization of protocols and protocol + usage in the Internet; + + - Facilitating technology transfer from the Internet Research Task + Force (IRTF) to the wider Internet community; and + + - Providing a forum for the exchange of information within the + Internet community between vendors, users, researchers, agency + contractors, and network managers. + + The IETF meeting is not a conference, although there are technical + presentations. The IETF is not a traditional standards organization, + although many specifications are produced that become standards. The + IETF is made up of volunteers, many of whom meet three times a year + to fulfill the IETF mission. + + There is no membership in the IETF. Anyone may register for and + attend any meeting. The closest thing there is to being an IETF + member is being on the IETF or Working Group mailing lists (see + Section 1.3). This is where the best information about current IETF + activities and focus can be found. + + Of course, no organization can be as successful as the IETF is + without having some sort of structure. In the IETF's case, that + structure is provided by other organizations, as described in BCP 11, + "The Organizations Involved in the IETF Standards Process." If you + participate in the IETF and only read one BCP, this is the one you + should read. + + + + + +Harris Informational [Page 4] + +RFC 3160 The Tao of IETF August 2001 + + +1.1 Humble Beginnings + + The first IETF meeting was held in January, 1986, at Linkabit in San + Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in + October, 1986, was the first that non-government vendors attended. + The concept of Working Groups was introduced at the 5th IETF meeting + at the NASA Ames Research Center in California in February, 1987. + The 7th IETF, held at MITRE in McLean, Virginia in July, 1987, was + the first meeting with over 100 attendees. + + The 14th IETF meeting was held at Stanford University in July 1989. + It marked a major change in the structure of the IETF universe. The + IAB (then Internet Activities Board, now Internet Architecture + Board), which until that time oversaw many "task forces," changed its + structure to leave only two: the IETF and the IRTF. The IRTF is + tasked to consider long-term research problems in the Internet. The + IETF also changed at that time. + + After the Internet Society (ISOC) was formed in January, 1992, the + IAB proposed to ISOC that the IAB's activities should take place + under the auspices of the Internet Society. During INET92 in Kobe, + Japan, the ISOC Trustees approved a new charter for the IAB to + reflect the proposed relationship. + + The IETF met in Amsterdam, The Netherlands, in July 1993. This was + the first IETF meeting held in Europe, and the US/non-US attendee + split was nearly 50/50. One in five IETF meetings are now held in + Europe or Asia, and the number of non-US attendees continues to be + high -- about 50%, even at meetings held in the US. + +1.2 The Hierarchy + +1.2.1 ISOC (Internet Society) + + The Internet Society is an international, non-profit, membership + organization that fosters the expansion of the Internet. One of the + ways that ISOC does this is through financial and legal support of + the other "I" groups described here, particularly the IETF. ISOC's + oversight of the IETF is remarkably hands-off, so many IETF + participants don't even know about it. ISOC provides insurance + coverage for many of the people in the IETF process, and acts as a + public relations channel for the times that one of the "I" groups + wants to say something to the press. The ISOC is one of the major + unsung (and under-funded) heroes of the Internet. + + + + + + + +Harris Informational [Page 5] + +RFC 3160 The Tao of IETF August 2001 + + +1.2.2 IESG (Internet Engineering Steering Group) + + The IESG is responsible for technical management of IETF activities + and the Internet standards process. It administers the process + according to the rules and procedures that have been ratified by the + ISOC Trustees. However, the IESG doesn't do much direct leadership, + such as the kind you will find in many other standards organizations. + The IESG ratifies or corrects the output from the IETF's Working + Groups, gets WGs started and finished, and makes sure that non-WG + drafts that are about to become RFCs are correct. + + The IESG consists of the Area Directors ("ADs"), who are selected by + the Nominations Committee (which is usually called "Nomcom") and are + appointed for two years. The process for choosing the members of the + IESG is detailed in BCP 10, "IAB and IESG Selection, Confirmation, + and Recall Process: Operation of the Nominating and Recall + Committees." + + The current areas and abbreviations are: + + - Applications (APP) Protocols seen by user programs, such as + e-mail and the Web + - General (GEN) Catch-all for WGs that don't fit in other + areas (which is very few) + - Internet (INT) Different ways of moving IP packets and DNS + information + - Operations and Operational aspects, network monitoring, + Management (OPS) and configuration + - Routing (RTG) Getting packets to their destinations + - Security (SEC) Authentication and privacy + - Transport (TSV) Special services for special packets + - User Services (USV) Support for end users and user support + organizations + + Because the IESG has a great deal of influence on whether Internet + Drafts become RFCs, many people look at the ADs as somewhat godlike + creatures. IETF participants sometimes reverently ask an Area + Director for their opinion on a particular subject. However, most + ADs are nearly indistinguishable from mere mortals and rarely speak + from mountaintops. In fact, when asked for specific technical + comments, the ADs may often defer to members at large whom they feel + have more knowledge than they do in that area. + + The ADs for a particular area are expected to know more about the + combined work of the WGs in that area than anyone else. On the other + hand, the entire IESG discusses each Internet Draft that is proposed + to become an RFC. At least two IESG members must express concerns + before a draft can be blocked from moving forward. These checks help + + + +Harris Informational [Page 6] + +RFC 3160 The Tao of IETF August 2001 + + + ensure that an AD's "pet project" doesn't make it onto the standards + track if it will have a negative effect on the rest of the IETF + protocols. + + This is not to say that the IESG never wields power. When the IESG + sees a Working Group veering from its charter, or when a WG asks the + IESG to make the WG's badly designed protocol a standard, the IESG + will act. In fact, because of its high workload, the IESG usually + moves in a reactive fashion. It approves most WG requests for + Internet Drafts to become RFCs, and usually only steps in when + something has gone very wrong. Another way to think about this is + that the ADs are selected to think, not to just run the process. The + quality of the IETF standards comes both from the review they get in + the Working Groups and the review that the WG review gets from the + ADs. + + The IETF is run by rough consensus, and it is the IESG that decides + if a WG has come up with a result that has a real consensus. Because + of this, one of the main reasons that the IESG might block something + that was produced in a WG is that the result did not really gain + consensus in the IETF as a whole, that is, among all of the Working + Groups in all areas. For instance, the result of one WG might clash + with a technology developed in a different Working Group. An + important job of the IESG is to watch over the output of all the WGs + to help prevent IETF protocols that are at odds with each other. + This is why ADs are supposed to review the drafts coming out of areas + other than their own. + +1.2.3 IAB (Internet Architecture Board) + + The IAB is responsible for keeping an eye on the "big picture" of the + Internet, and focuses on long-range planning and coordination among + the various areas of IETF activity. The IAB stays informed about + important long-term issues in the Internet, and brings these topics + to the attention of people they think should know about them. + + IAB members pay special attention to emerging activities in the IETF. + When a new IETF working group is proposed, the IAB reviews its + charter for architectural consistency and integrity. Even before the + group is chartered, the IAB members are more than willing to discuss + new ideas with the people proposing them. + + The IAB also sponsors and organizes the Internet Research Task Force, + and convenes invitational workshops that provide in-depth reviews of + specific Internet architectural issues. Typically, the workshop + reports make recommendations to the IETF community and to the IESG. + + + + + +Harris Informational [Page 7] + +RFC 3160 The Tao of IETF August 2001 + + + The IAB also: + + - Approves Nomcom's IESG nominations + - Acts as the appeals board for appeals against IESG actions + - Appoints and oversees the RFC Editor + - Approves the appointment of the IANA + - Acts as an advisory body to the ISOC + - Oversees IETF liaisons with other standards bodies + + Like the IESG, the IAB members are selected for multi-year positions + by the Nomcom, and are approved by the Board of Trustees of the ISOC. + +1.2.4 IANA (Internet Assigned Numbers Authority) + + The core registrar for the IETF's activities is the IANA. Many + Internet protocols require that someone keep track of protocol items + that were added after the protocol came out. Typical examples of the + kinds of registries needed are for TCP port numbers and MIME types. + The IAB has designated the IANA organization to perform these tasks, + and the IANA's activities are financially supported by ICANN, the + Internet Corporation for Assigned Names and Numbers. + + Five years ago, no one would have expected to ever see the IANA + mentioned on the front page of a newspaper. IANA's role had always + been very low key. The fact that IANA was also the keeper of the + root of the domain name system forced it to become a much more public + entity, one which was badly maligned by a variety of people who never + looked at what its role was. Nowadays the IETF is generally no + longer involved in the IANA's domain name and IP address assignment + functions, which are overseen by ICANN. + + Even though being a registrar may not sound interesting, many IETF + participants will testify to how important IANA has been for the + Internet. Having a stable, long-term repository run by careful and + conservative operators makes it much easier for people to experiment + without worrying about messing things up. IANA's founder, Jon + Postel, was heavily relied upon to keep things in order while the + Internet kept growing by leaps and bounds, and he did a fine job of + it until his untimely death in 1998. + +1.2.5 RFC Editor + + The RFC Editor edits, formats, and publishes Internet Drafts as RFCs, + working in conjunction with the IESG. An important secondary role is + to provide one definitive repository for all RFCs (see + http://www.rfc-editor.org). Once an RFC is published, it is never + revised. If the standard it describes changes, the standard will be + re-published in another RFC that "obsoletes" the first. + + + +Harris Informational [Page 8] + +RFC 3160 The Tao of IETF August 2001 + + + One of the most popular misconceptions in the IETF community is that + the role of the RFC Editor is performed by IANA. In fact, the RFC + Editor is a separate job, although both the RFC Editor and IANA + involved the same people for many years. The IAB approves the + organization that will act as RFC Editor and the RFC Editor's general + policy. The RFC Editor is funded by ISOC and can be contacted by e- + mail at rfc-ed@rfc-editor.org. + +1.2.6 IETF Secretariat + + There are, in fact, a few people who are paid to maintain the IETF. + The IETF Secretariat provides day-to-day logistical support, which + mainly means coordinating face-to-face meetings and running the + IETF-specific mailing lists (not the WG mailing lists). The + Secretariat is also responsible for keeping the official Internet + Drafts directory up to date and orderly, maintaining the IETF Web + site, and for helping the IESG do its work. The IETF Secretariat is + financially supported by the fees of the face-to-face meetings. + +1.3 IETF Mailing Lists + + Anyone who plans to attend an IETF meeting should join the IETF + announcement mailing list, "ietf-announce@ietf.org". This is where + all of the meeting information, Internet Draft and RFC announcements, + and IESG Protocol Actions and Last Calls are posted. People who + would like to "get technical" may also join the IETF discussion list, + "ietf@ietf.org". This is where discussions of cosmic significance + are held (Working Groups have their own mailing lists for discussions + related to their work). + + Subscriptions to these and other IETF mailing lists are handled by a + program called Majordomo. Majordomo tends to be somewhat finicky + about the format of subscription messages, and interacts poorly with + email programs that make all email messages into HTML files. + Majordomo will treat you well, however, if you format your messages + just the way it likes. To join the IETF announcement list, for + example, send email to: + + ietf-announce-request@ietf.org + + Enter the word 'subscribe' (without the quotes) in the Subject line + of the message and in the message body. To join the IETF discussion + list, send email to: + + ietf-request@ietf.org + + + + + + +Harris Informational [Page 9] + +RFC 3160 The Tao of IETF August 2001 + + + and enter the word 'subscribe' as explained above. If you decide to + withdraw from either list, use the word 'unsubscribe.' Your messages + to Majordomo should have nothing other than the commands 'subscribe' + or 'unsubscribe' in them. + + Both lists are archived on the IETF web site: + + http://www.ietf.org/maillist.html + + Do not, ever, under any circumstances, for any reason, send a request + to join a list to the list itself! The thousands of people on the + list don't need, or want, to know when a new person joins. + Similarly, when changing e-mail addresses or leaving a list, send + your request only to the "-request" address, not to the main list. + This means you!! + + The IETF discussion list is unmoderated. This means that anyone can + express their opinions about issues affecting the Internet. However, + it is not a place for companies or individuals to solicit or + advertise, as noted in "IETF Discussion List Charter," RFC 3005. It + is a good idea to read the whole RFC (it's short!) before posting to + the IETF discussion list. + + Only the Secretariat can send messages to the announcement list. + + Even though the IETF mailing lists "represent" the IETF membership at + large, it is important to note that attending an IETF meeting does + not mean you'll be automatically added to either mailing list. + +2. IETF Meetings + + The computer industry is rife with conferences, seminars, + expositions, and all manner of other kinds of meetings. IETF face- + to-face meetings are nothing like these. The meetings, held three + times a year, are week-long dweebfests whose primary goal is to + reinvigorate the WGs to get their tasks done, and whose secondary + goal is to promote a fair amount of mixing between the WGs and the + areas. The cost of the meetings is paid by the people attending and + by the corporate host for each meeting, although ISOC kicks in + additional funds for things like the multicast simulcast of some + Working Group sessions. + + For many people, IETF meetings are a breath of fresh air when + compared to the standard computer industry conferences. There is no + exposition hall, few tutorials, and no big-name industry pundits. + Instead, there is lots of work, as well as a fair amount of time for + socializing. IETF meetings are of little interest to sales and + marketing folks, but of high interest to engineers and developers. + + + +Harris Informational [Page 10] + +RFC 3160 The Tao of IETF August 2001 + + + Most IETF meetings are held in North America, because that's where + most of the participants are from; however, meetings are held on + other continents about once every year or two. The past few meetings + have had about 2,500 attendees. There have been over 50 IETF + meetings so far, and a list of upcoming meetings is available on the + IETF web pages, http://www.ietf.org/meetings/0mtg-sites.txt. + + Newcomers to IETF face-to-face meetings are often in a bit of shock. + They expect them to be like other standards bodies, or like computer + conferences. Fortunately, the shock wears off after a day or two, + and many new attendees get quite animated about how much fun they are + having. One particularly jarring feature of recent IETF meetings is + the use of wireless Internet connections throughout the meeting + space. It is common to see half the people in a WG meeting reading + e-mail or perusing the web during presentations they find + uninteresting. + +2.1 Registration + + To attend an IETF meeting you have to register and you have to pay + the registration fee. The meeting site and advance registration are + announced about two months ahead of the meeting -- earlier if + possible. An announcement goes out via e-mail to the IETF-announce + mailing list, and information is posted on the IETF web site, + http://www.ietf.org, that same day. + + To pre-register, you must submit your registration on the Web. You + may pre-register and pre-pay, pre-register and return to the Web site + later to pay with a credit card, pre-register and pay on-site at the + meeting, or register and pay on-site. To get a lower registration + fee, you must pay by the early registration deadline (about one week + before the meeting). The registration fee covers all of the week's + meetings, the Sunday evening reception (cash bar), daily continental + breakfasts, and afternoon coffee breaks. + + Credit card payments on the web are encrypted and secure, or, if you + prefer, you can use PGP to send your payment information to the + Registrar (ietf-registrar@ietf.org). + + Registration is open throughout the week of the meeting. However, + the Secretariat highly recommends that attendees arrive for early + registration, beginning at noon on Sunday and continuing throughout + the 5:00 Sunday evening reception. The reception is a popular event + where you can get a bite to eat and socialize with other early + arrivals. + + + + + + +Harris Informational [Page 11] + +RFC 3160 The Tao of IETF August 2001 + + + Registered attendees (and there aren't any other kind) receive a + registration packet. It contains much useful information, including + a general orientation sheet, the most recent agenda, and a name tag. + Attendees who pre-paid will also find their receipt in their packet. + It's worth noting that neither attendee names and addresses or IETF + mailing lists are ever offered for sale. + +2.2 Newcomers' Orientation + + Newcomers are encouraged to attend the Newcomers' Orientation, which + is especially designed for first-time attendees. The orientation is + organized and conducted by the IETF Secretariat, and is intended to + provide useful introductory information. The orientation is + typically about 30 minutes long and covers what's in the attendee + packets, what all the dots on name tags mean, the structure of the + IETF, and many other essential and enlightening topics for new + IETFers. + + Immediately following the Newcomers' Orientation is the IETF + Standards Process Orientation. This session demystifies much of the + standards process by explaining what stages a document has to pass + through on its way to becoming a standard, and what has to be done to + advance to the next stage. The Standards Process Orientation also + lasts about 30 minutes. + + There is ample time at the end for questions. The Secretariat also + provides handouts that include an overview of the IETF, a list of + important files available online, and hard copies of the slides of + the "IETF Structure and Internet Standards Process" presentation. + These very useful slides are also available online at www.ietf.org + under "Additional Information". + + The orientation is held on Sunday afternoon before the 5:00 p.m. + reception (check the agenda for exact time and location). Be advised + that attending the orientation does NOT mean you can go to the + reception early! + +2.3 Dress Code + + Since attendees must wear their name tags, they must also wear shirts + or blouses. Pants or skirts are also highly recommended. Seriously + though, many newcomers are often embarrassed when they show up Monday + morning in suits, to discover that everybody else is wearing t- + shirts, jeans (shorts, if weather permits) and sandals. There are + those in the IETF who refuse to wear anything other than suits. + Fortunately, they are well known (for other reasons) so they are + + + + + +Harris Informational [Page 12] + +RFC 3160 The Tao of IETF August 2001 + + + forgiven this particular idiosyncrasy. The general rule is "dress + for the weather" (unless you plan to work so hard that you won't go + outside, in which case, "dress for comfort" is the rule!). + +2.4 Seeing Spots Before Your Eyes + + Some of the people at the IETF will have a little colored dot on + their name tag. A few people have more than one. These dots + identify people who are silly enough to volunteer to do a lot of + extra work. The colors have the following meanings: + + blue - Working Group/BOF chair + green - Host group + red - IAB member + yellow - IESG member + orange - Nominating Committee member + + (Members of the press wear orange-tinted badges.) + + Local hosts are the people who can answer questions about the + terminal room, restaurants, and points of interest in the area. + + It is important that newcomers to the IETF not be afraid to strike up + conversations with people who wear these dots. If the IAB and IESG + members and Working Group and BOF chairs didn't want to talk to + anybody, they wouldn't be wearing the dots in the first place. + +2.5 Terminal Room + + One of the most important (depending on your point of view) things + the host does is provide Internet access for the meeting attendees. + In general, wired and wireless connectivity is excellent. This is + entirely due to the Olympian efforts of the local hosts, and their + ability to beg, borrow and steal. The people and companies who + donate their equipment, services and time are to be heartily + congratulated and thanked. + + While preparation far in advance of the meeting is encouraged, there + may be some unavoidable "last minute" things that can be accomplished + in the terminal room. It may also be useful to people who need to + make trip reports or status reports while things are still fresh in + their minds. The terminal room provides workstations, one or two + printers, and ports for laptops. + + + + + + + + +Harris Informational [Page 13] + +RFC 3160 The Tao of IETF August 2001 + + +2.6 Meals and Other Delights + + Marshall Rose once remarked that the IETF was a place to go for "many + fine lunches and dinners." While it is true that some people eat + very well at the IETF, they find the food on their own; lunches and + dinners are not included in the registration fee. The Secretariat + does provide appetizers at the Sunday evening reception (not meant to + be a replacement for dinner), continental breakfast every morning, + and (best of all) cookies, brownies and other yummies during + afternoon breaks. + + If you prefer to get out of the hotel for meals, the local host + usually provides a list of places to eat within easy reach of the + meeting site. + +2.7 Social Event + + Another of the most important things organized and managed by the + host is the IETF social event. Sometimes, the social event is a + computer or high-tech related event. At the Boston IETF, for + example, the social was dinner at the Computer Museum. Other times, + the social might be a dinner cruise or a trip to an art gallery. + + Newcomers to the IETF are encouraged to attend the social event. + Everyone is encouraged to wear their name tags and leave their + laptops behind. The social event is designed to give people a chance + to meet on a social, rather than technical, level. + +2.8 Agenda + + The agenda for the IETF meetings is a very fluid thing. It is sent, + updated, to the IETF announcement list three times prior to the + meeting, and is also available on the web. The agenda for the 50th + IETF, for example, is at http://www.ietf.org/meetings/agenda_50.html. + The final agenda is included in the registration packets. Of course, + "final" in the IETF doesn't mean the same thing as it does elsewhere + in the world. The final agenda is simply the version that went to + the printer. The Secretariat will post agenda changes on the + bulletin board near the IETF registration desk (not the hotel + registration desk). + + Assignments for breakout rooms (where the Working Groups and BOFs + meet) and a map showing the room locations are also shown on the + agenda. Room assignments can change as the agenda changes. Some + Working Groups meet multiple times during a meeting and every attempt + is made to have a Working Group meet in the same room for each + session. + + + + +Harris Informational [Page 14] + +RFC 3160 The Tao of IETF August 2001 + + +2.9 Where Do I Fit In? + + The IETF is different things to different people. There are many + people who have been very active in the IETF who have never attended + an IETF meeting. You should not feel obligated to come to an IETF + meeting just to get a feel for the IETF. The following guidelines + (based on stereotypes of people in various industries) might help you + decide whether you actually want to come and, if so, what might be + the best use of your time at your first meeting. + +2.9.1 IS Managers + + As discussed throughout this document, an IETF meeting is nothing + like any trade show you have attended. IETF meetings are singularly + bad places to go if your intention is to find out what will be hot in + the Internet industry next year. You can safely assume that going to + Working Group meetings will confuse you more than it will help you + understand what is happening, or will be happening, in the industry. + + This is not to say that no one from industry should go to IETF + meetings. As an IS manager, you might want to consider sending + specific people who are responsible for technologies that are under + development in the IETF. As these people read the current Internet + Drafts and the traffic on the relevant Working Group lists, they will + get a sense of whether or not their presence would be worthwhile for + your company or for the Working Groups. + +2.9.2 Network Operators and ISPs + + Running a network is hard enough without having to grapple with new + protocols or new versions of the protocols with which you are already + dealing. If you work for the type of network that is always using + the very latest hardware and software, and you are following the + relevant Working Groups in your copious free time, you might find + attending the IETF meeting valuable. The closer you are to the + bleeding edge of networking, particularly in the areas of routing and + switching, the more likely it is that you will be able to learn and + contribute at an IETF meeting. + +2.9.3 Networking Hardware and Software Vendors + + The image of the IETF being mostly ivory tower academics may have + been true in the past, but the jobs of typical attendees are now in + industry. In most areas of the IETF, employees of vendors are the + ones writing the protocols and leading the Working Groups, so it's + completely appropriate for vendors to attend. If you create Internet + hardware or software, and no one from your company has ever attended + an IETF meeting, it behooves you to come to a meeting if for no other + + + +Harris Informational [Page 15] + +RFC 3160 The Tao of IETF August 2001 + + + reason than to tell the others how relevant the meeting was or was + not to your business. + + This is not to say that companies should close up shop during IETF + meeting weeks so everyone can go to the meeting. Marketing folks, + even technical marketing folks, are usually safe in staying away from + the IETF as long as some of the technical people from the company are + at the meeting. Similarly, it isn't required, or likely useful, for + everyone from a technical department to go, particularly if they are + not all reading the Internet Drafts and following the Working Group + mailing lists. Many companies have just a few designated meeting + attendees who are chosen for their ability to do complete and useful + trip reports. + +2.9.4 Academics + + IETF meetings are often excellent places for computer science folk to + find out what is happening in the way of soon-to-be-deployed + protocols. Professors and grad students (and sometimes overachieving + undergrads) who are doing research in networking or communications + can get a wealth of information by following Working Groups in their + specific fields of interest. Wandering into different Working Group + meetings can have the same effect as going to symposia and seminars + in your department. + +2.9.5 Computer Trade Press + + If you're a member of the press and are considering attending IETF, + we've prepared a special section of the Tao just for you -- please + see Section 8.2. + +2.10 Proceedings + + IETF proceedings are compiled in the two months following each + meeting, and are available on the web, on CD, and in print. Be sure + to look through a copy -- the proceedings are filled with information + about IETF that you're not likely to find anywhere else. For + example, you'll find snapshots of most WG charters at the time of the + meeting, giving you a better understanding of the evolution of any + given effort. + + The proceedings usually start with an informative (and highly + entertaining) message from Steve Coya, the Executive Director of the + IETF. Each volume of contains the final (hindsight) agenda, an IETF + overview, area and Working Group reports, and slides from the + protocol and technical presentations. The Working Group reports and + presentations are sometimes incomplete, if the materials haven't been + turned in to the Secretariat in time for publication. + + + +Harris Informational [Page 16] + +RFC 3160 The Tao of IETF August 2001 + + + An attendee list is also included, and contains names, affiliations, + work and fax phone numbers, and e-mail addresses as provided on the + registration form. For information about obtaining copies of the + proceedings, see the Web listing at + http://www.ietf.org/proceedings/directory.html. + +2.11 Other General Things + + The IETF Secretariat, and IETFers in general, are very approachable. + Never be afraid to approach someone and introduce yourself. Also, + don't be afraid to ask questions, especially when it comes to jargon + and acronyms! + + Hallway conversations are very important. A lot of very good work + gets done by people who talk together between meetings and over + lunches and dinners. Every minute of the IETF can be considered work + time (much to some people's dismay). + + A "bar BOF" is an unofficial get-together, usually in the late + evening, during which a lot of work gets done over drinks. Bar BOFs + spring up in many different places around an IETF meeting, such as + restaurants, coffee shops, and (if we are so lucky) pools. + + It's unwise to get between a hungry IETFer (and there isn't any other + kind) and coffee break brownies and cookies, no matter how + interesting a hallway conversation is. + + IETFers are fiercely independent. It's safe to question opinions and + offer alternatives, but don't expect an IETFer to follow orders. + + The IETF, and the plenary session in particular, are not places for + vendors to try to sell their wares. People can certainly answer + questions about their company and its products, but bear in mind that + the IETF is not a trade show. This does not preclude people from + recouping costs for IETF-related t-shirts, buttons and pocket + protectors. + + There is always a "materials distribution table" near the + registration desk. This desk is used to make appropriate information + available to the attendees (e.g., copies of something discussed in a + Working Group session, descriptions of online IETF-related + information, etc.). Please check with the Secretariat before placing + materials on the desk; the Secretariat has the right to remove + material that they feel is not appropriate. + + + + + + + +Harris Informational [Page 17] + +RFC 3160 The Tao of IETF August 2001 + + +3.0 Working Groups + + The vast majority of the IETF's work is done in many "Working + Groups;" at the time of this writing, there are about 115 different + WGs. (The term "Working Group" is often seen capitalized, but + probably not for a very good reason.) BCP 25, "IETF Working Group + Guidelines and Procedures," is an excellent resource for anyone + participating in WG discussions. + + A WG is really just a mailing list with a bit of adult supervision. + You "join" the WG by subscribing to the mailing list; all mailing + lists are open to anyone. Some IETF WG mailing lists only let + subscribers to the mailing list post to the mailing list, while + others let anyone post. Each Working Group has one or two chairs. + + More importantly, each WG has a charter that the WG is supposed to + follow. The charter states the scope of discussion for the Working + Group, as well as its goals. The WG's mailing list and face-to-face + meetings are supposed to focus on just what is in the charter, and + not to wander off on other "interesting" topics. Of course, looking + a bit outside the scope of the WG is occasionally useful, but the + large majority of the discussion should be on the topics listed in + the charter. In fact, some WG charters actually specify what the WG + will not do, particularly if there were some attractive but nebulous + topics brought up during the drafting of the charter. The list of + all WG charters makes interesting reading for folks who want to know + what the different Working Groups are supposed to be doing. + +3.1 Working Group Chairs + + The role of the WG chairs is described in both BCP 11 and BCP 25. + Basically, their job is to keep the discussion moving forward towards + the milestones in the WG charter -- usually publication of one or + more RFCs. They are not meant to be taskmasters, but are responsible + for assuring positive forward motion and preventing random wandering. + + As you can imagine, some Working Group chairs are much better at + their jobs than others. When a WG has fulfilled its charter, it is + supposed to cease operations. (Most WG mailing lists continue on + after a WG is closed, still discussing the same topics as the Working + Group did.) In the IETF, it is a mark of success that the WG closes + up because it fulfilled its charter. This is one of the aspects of + the IETF that newcomers who have experience with other standards + bodies have a hard time understanding. However, some WG chairs never + manage to get their WG to finish, or keep adding new tasks to the + charter so that the Working Group drags on for many years. The + output of these aging WGs is often not nearly as useful as the + + + + +Harris Informational [Page 18] + +RFC 3160 The Tao of IETF August 2001 + + + earlier products, and the messy results are sometimes called + "degenerative Working Group syndrome." + + One important role of the chair is to decide which Internet Drafts + get published as "official" Working Group drafts, and which don't. + In practice, there is actually not much procedural difference between + WG drafts and independent drafts; for example, many WG mailing lists + also discuss independent drafts (at the discretion of the WG chair). + Procedures for Internet Drafts are covered in much more detail later + in this document. + + WG chairs are strongly advised to go to the new chairs' training + lunch the first day of the IETF meeting. If you're interested in + what they hear there, take a look at the slides at + http://www.ietf.org/wgchair/index.htm. + +3.2 Getting Things Done in a Working Group + + One fact that confuses many novices is that the face-to-face WG + meetings are much less important in the IETF than they are in most + other organizations. Any decision made at a face-to-face meeting + must also gain consensus on the WG mailing list. There are numerous + examples of important decisions made in WG meetings that are later + overturned on the mailing list, often because someone who couldn't + attend the meeting pointed out a serious flaw in the logic used to + come to the decision. + + Another aspect of Working Groups that confounds many people is the + fact that there is no formal voting. The general rule on disputed + topics is that the Working Group has to come to "rough consensus," + meaning that a very large majority of those who care must agree. The + exact method of determining rough consensus varies from Working Group + to Working Group. The lack of voting has caused some very long + delays for some proposals, but most IETF participants who have + witnessed rough consensus after acrimonious debates feel that the + delays often result in better protocols. (And, if you think about + it, how could you have "voting" in a group that anyone can join, and + when it's impossible to count the participants?) + +3.3 Preparing for Working Group Meetings + + The most important thing that everyone (newcomers and seasoned + experts) should do before coming to a face-to-face meeting is to read + the Internet Drafts and RFCs beforehand. WG meetings are explicitly + not for education: they are for developing the group's documents. + Even if you do not plan to say anything in the meeting, you should + read the group's documents before attending so you can understand + what is being said. + + + +Harris Informational [Page 19] + +RFC 3160 The Tao of IETF August 2001 + + + It's up to the WG chair to set the meeting agenda, usually a few + weeks in advance. If you want something discussed at the meeting, be + sure to let the chair know about it. The agendas for all the WG + meetings are available in advance (see + http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the + meeting number), but many WG chairs are lax (if not totally + negligent) about turning them in. + + The Secretariat only schedules WG meetings a few weeks in advance, + and the schedule often changes as little as a week before the first + day. If you are only coming for one WG meeting, you may have a hard + time booking your flight with such little notice, particularly if the + Working Group's meeting changes schedule. Be sure to keep track of + the current agenda so you can schedule flights and hotels. But, when + it comes down to it, you probably shouldn't be coming for just one WG + meeting. It's likely that your knowledge could be valuable in a few + WGs, assuming that you've read the drafts and RFCs for those groups. + + If you're giving a presentation at a face-to-face meeting, you should + probably come with a few slides prepared. Projectors for laptop- + based presentations are available in all the meeting rooms. And + here's a tip for your slides: don't put your company's logo on every + one, even though it's common practice outside the IETF. The IETF + frowns on this kind of corporate advertising, and most presenters + don't even put their logo on their opening slide. The IETF is about + technical content, not company boosterism. + +3.4 Working Group Mailing Lists + + As we mentioned earlier, the IETF announcement and discussion mailing + lists are the central mailing lists for IETF activities. However, + there are many other mailing lists related to IETF work. For + example, every Working Group has its own discussion list. In + addition, there are some long-term technical debates that have been + moved off of the IETF list onto lists created specifically for those + topics. It is highly recommended that everybody follow the + discussions on the mailing lists of the Working Groups that they wish + to attend. The more work that is done on the mailing lists, the less + work that will need to be done at the meeting, leaving time for cross + pollination (i.e., attending Working Groups outside one's primary + area of interest in order to broaden one's perspective). + + The mailing lists also provide a forum for those who wish to follow, + or contribute to, the Working Groups' efforts, but can't attend the + IETF meetings. + + + + + + +Harris Informational [Page 20] + +RFC 3160 The Tao of IETF August 2001 + + + Most IETF discussion lists use Majordomo and have a "-request" + address which handles the administrative details of joining and + leaving the list. (See Section 1.3 for more information on + Majordomo.) It is generally frowned upon when such administrivia + appears on the discussion mailing list. + + Most IETF discussion lists are archived. That is, all of the + messages sent to the list are automatically stored on a host for + anonymous FTP access. Many such archives are listed online at + ftp://ftp.ietf.org/ietf-mail-archive/. If you don't find the list + you're looking for, send a message to the list's "-request" address + (not to the list itself!). + +3.5 Interim Working Group Meetings + + Working groups sometimes hold interim meetings between IETFs. + Interim meetings aren't a substitute for IETF meetings, however -- a + group can't decide to skip a meeting in a location they're not fond + of and meet in Cancun three weeks later, for example. Interim + meetings require AD approval, and need to be announced at least one + month in advance. Location and timing need to allow fair access for + all participants. Like regular IETF meetings, someone needs to take + notes and send them to minutes@ietf.org, and the group needs to take + attendance. + +4. BOFs + + In order to form a Working Group, you need a charter and someone who + is able to be chair. In order to get those things, you need to get + people interested so that they can help focus the charter and + convince an Area Director that the project is worthwhile. A face- + to-face meeting is useful for this. In fact, very few WGs get + started by an Area Director; most start after a face-to-face BOF + because attendees have expressed interest in the topic. + + A BOF meeting has to be approved by the Area Director in the relevant + area before it can be scheduled. If you think you really need a new + WG, approach an AD informally with your proposal and see what they + think. The next step is to request a meeting slot at the next face- + to-face meeting. Of course, you don't need to wait for that meeting + to get some work done, such as setting up a mailing list and starting + to discuss a charter. + + BOF meetings have a very different tone than WG meetings. The + purpose of a BOF is to make sure that a good charter with good + milestones can be created, and that there are enough people willing + to do the work needed in order to create standards. Some BOFs have + Internet Drafts already in process, while others start from scratch. + + + +Harris Informational [Page 21] + +RFC 3160 The Tao of IETF August 2001 + + + An advantage of having a draft before the BOF is to help focus the + discussion. On the other hand, having a draft might tend to limit + what the other folks in the BOF want to do in the charter. It's + important to remember that most BOFs are held in order to get support + for an eventual Working Group, not to get support for a particular + document. + + Many BOFs don't turn into WGs for a variety of reasons. A common + problem is that not enough people can agree on a focus for the work. + Another typical reason is that the work wouldn't end up being a + standard -- if, for example, the document authors don't really want + to relinquish change control to a WG. (We'll discuss change control + later in this document.) Only two meetings of a BOF can be scheduled + on a particular subject; either a WG has to form, or the topic should + be dropped. + +5. ** New to the IETF? STOP HERE! (Temporarily) ** + ----------------------------------------- + If you're new to the IETF and this is the only reference you plan to + read before coming to the meeting, stop here -- at least temporarily. + Then, on your flight home, read the rest of the Tao. By that time + you'll be ready to get actively involved in the Working Groups that + interested you at the meeting, and the Tao will get you started on + your way. + +6. RFCs and Internet Drafts + + If you're a new IETF participant and are looking for a particular RFC + or Internet Draft, go to the RFC Editor's Web pages, http://www.rfc- + editor.org/rfc.html. That site also has links to other RFC + collections, many with search capabilities. If you know the number + of the RFC you're looking for, go to the IETF RFC pages, + http://www.ietf.org/rfc.html. For Internet Drafts, the best resource + is the IETF web site, http://www.ietf.org/ID.html, where you can + search by title and keyword. + +6.1 Getting a Standard Published + + One of the most common questions seasoned IETFers hear from newcomers + is, "How do I get an IETF standard published?" A much better + question is, "Should I write an IETF standard?" since the answer is + not always "yes." If you do decide to try to write a document that + becomes an IETF standard, be warned that the overall process may be + arduous, even if the individual steps are fairly straightforward. + Lots of people get through the process unscathed, though, and there's + plenty of written guidance that helps authors emerge with their ego + more or less intact. + + + + +Harris Informational [Page 22] + +RFC 3160 The Tao of IETF August 2001 + + + Every IETF standard is published as an RFC (a "Request For Comments," + but everyone just calls them RFCs), and every RFC starts out as an + Internet Draft (often called an "I-D"). The basic steps for getting + something published as an IETF standard are: + + 1. Publish the document as an Internet Draft + 2. Receive comments on the draft + 3. Edit your draft based on the comments + 4. Repeat steps 1 through 3 a few times + 5. Ask an Area Director to take the draft to the IESG (if it's an + individual submission). If the draft is an official Working + Group product, the WG chair asks the AD to take it to the IESG. + 6. Make any changes deemed necessary by the IESG (this might + include giving up on becoming a standard) + 7. Wait for the document to be published by the RFC Editor + + A much more complete explanation of these steps is contained in BCP + 9, "The Internet Standards Process." Anyone who writes a draft that + they hope will become an IETF standard must read BCP 9 so that they + can follow the path of their document through the process. BCP 9 + goes into great detail on a topic that is very often misunderstood, + even by seasoned IETF participants: different types of RFCs go + through different processes and have different rankings. There are + six kinds of RFCs: + + - Proposed standards + - Draft standards + - Internet standards (sometimes called "full standards") + - Experimental protocols + - Informational documents + - Historic standards + + Only the first three (proposed, draft, and full) are standards within + the IETF. A good summary of this can be found in the aptly titled + RFC 1796, "Not All RFCs are Standards." + + There are also three sub-series of RFCs, known as FYIs, BCPs, and + STDs. The For Your Information RFC sub-series was created to + document overviews and topics which are introductory or appeal to a + broad audience. Frequently, FYIs are created by groups within the + IETF User Services Area. Best Current Practice documents describe + the application of various technologies in the Internet. The STD RFC + sub-series was created to identify RFCs that do in fact specify + Internet standards. Some STDs are actually sets of more than one + RFC, and the "standard" designation applies to the whole set of + documents. + + + + + +Harris Informational [Page 23] + +RFC 3160 The Tao of IETF August 2001 + + +6.2 Letting Go Gracefully + + The biggest reason some people do not want their documents put on the + IETF standards track is that they must give up change control of the + protocol. That is, as soon as you propose that your protocol become + an IETF standard, you must fully relinquish control of the protocol. + If there is general agreement, parts of the protocol can be + completely changed, whole sections can be ripped out, new things can + be added, and the name can be changed. + + Some authors find it very hard to give up control of their pet + protocol. If you are one of those people, don't even think about + trying to get your protocol to become an IETF standard. On the other + hand, if your goal is the best standard possible with the widest + implementation, then you might find the IETF process to your liking. + + Incidentally, the change control on Internet standards doesn't end + when the protocol is put on the standards track. The protocol itself + can be changed later for a number of reasons, the most common of + which is that implementors discover a problem as they implement the + standard. These later changes are also under the control of the + IETF, not the editors of the standards document. + + IETF standards exist so that people will use them to write Internet + programs that interoperate. They don't exist to document the + (possibly wonderful) ideas of their authors, nor do they exist so + that a company can say "we have an IETF standard." If a standards- + track RFC only has one implementation (whereas two are required for + it to advance on the standards track), it was probably a mistake to + put it on the standards track in the first place. + +6.3 Internet Drafts + + First things first. Every document that ends up in the RFC + repository starts life as an Internet Draft. Internet Drafts are + tentative documents -- they're meant for readers to comment on, so + authors can mull over those comments and decide which ones to + incorporate in the draft. In order to remind folks of their + tentativeness, Internet Drafts are automatically removed from the + online directories after six months. They are most definitely not + standards or even specifications. As BCP 9 says: + + An Internet Draft is NOT a means of "publishing" a specification; + specifications are published through the RFC mechanism ... + Internet Drafts have no formal status, and are subject to change + or removal at any time. Under no circumstances should an Internet + Draft be referenced by any paper, report, or Request-for-Proposal, + nor should a vendor claim compliance with an Internet Draft. + + + +Harris Informational [Page 24] + +RFC 3160 The Tao of IETF August 2001 + + + You can always tell a person who doesn't understand the IETF (or is + intentionally trying to fool people) when they brag about having + published an Internet Draft; it takes no significant effort. + + An I-D should have approximately the same format as an RFC. Contrary + to many people's beliefs, an I-D does not need to look exactly like + an RFC, but if you can use the same formatting procedures used by the + RFC Editor when you create your I-Ds, it will simplify the RFC + Editor's work when your draft is published as an RFC. RFC 2223, + "Instructions to RFC Authors," describes the nroff formatting used by + the RFC Editor. + + An Internet Draft can be either a Working Group draft or an + individual submission. Working Group drafts are usually reviewed by + the chair before being accepted as a WG item. + +6.3.1 Recommended Reading for Writers + + Before you create the first draft of your Internet Draft, you should + read four documents: + + - More important than just explaining formatting, RFC 2223 also + explains what needs to be in an Internet Draft before it can + become an RFC. This document describes all the sections and + notices that will need to be in your document, and it's good to + have them there from the beginning so that readers aren't + surprised when you put them in later versions. + + - BCP 22, "Guide for Internet Standards Writers," provides tips + that will help you write a standard that leads to + interoperability. For instance, it explains how to choose the + right number of protocol options, how to respond to out-of-spec + behavior, and how to show state diagrams. + + - The online "Guidelines to Authors of Internet Drafts," + http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date + information about the process for turning in Internet Drafts, as + well as the most current boilerplate information that has to be + included in each Internet Draft. + + - When you think you are finished with the draft process and are + ready to request that the draft become an RFC, you should + definitely read "Considerations for Internet Drafts," + http://www.ietf.org/ID-nits.html, a list of common "nits" that + have been known to stop documents in the IESG. In fact, you + should probably read that document well before you are finished, + so that you don't have to make a bunch of last-minute changes. + + + + +Harris Informational [Page 25] + +RFC 3160 The Tao of IETF August 2001 + + +6.3.2 Filenames and Other Matters + + When you're ready to turn in your Internet Draft, send it to the + Internet Drafts editor at internet-drafts@ietf.org. There is a real + person at the other end of this mail address -- their job is to make + sure you've included the minimum items you need for the Internet + Draft to be published. When you submit the first version of the + draft, the draft editor supplies the filename for the draft. If the + draft is an official Working Group product, the name will start with + "draft-ietf-" followed by the designation of the WG, followed by a + descriptive word or two, followed by "00.txt". + + For example, a draft in the S/MIME WG about creating keys might be + named "draft-ietf-smime-keying-00.txt". If it's not the product of a + Working Group, the name will start with "draft-" and the last name of + one of the authors followed by a descriptive word or two, followed by + "00.txt". For example, a draft that someone named Smith wrote might + be named "draft-smith-keying-00.txt". If a draft is an individual + submission but relates to a particular working group, the author + sometimes follows their name with the name of the working group, such + as "draft-smith-smime-keying-00.txt". You are welcome to suggest + names; however, it is up to the Internet Drafts editor (and, if it is + an official WG draft, the WG chair) to come up with the filename. + + After the first edition of a draft, the number in the filename is + incremented; for instance, the second edition of the S/MIME draft + named above would be "draft-ietf-smime-keying-01.txt". Note that + there are cases where the filename changes after the first version, + such as when a personal effort is pulled into a Working Group. + +6.4 Standards-Track RFCs + + The procedure for creating and advancing a standard is described in + BCP 9. After an Internet Draft has been sufficiently discussed and + there is rough consensus that what it says would be a useful + standard, it is presented to the IESG for consideration. If the + draft is an official WG draft, the WG chair sends it to the + appropriate Area Director after it has gone through Working Group + last call. If the draft is an individual submission, the draft's + author or editor submits it to the appropriate Area Director. BCP 9 + also describes the appeals process for people who feel that a Working + Group chair, an AD, or the IESG has made the wrong decision in + considering the creation or advancement of a standard. + + After it is submitted to the IESG, the IESG announces an IETF-wide + last call. This helps get the attention of people who weren't + following the progress of the draft, and can sometimes cause further + changes to the draft. It is also a time when people in the WG who + + + +Harris Informational [Page 26] + +RFC 3160 The Tao of IETF August 2001 + + + feel that they weren't heard can make their comments to everyone. + The IETF last call is two weeks for drafts coming from WGs and four + weeks for individual submissions. + + If the IESG approves the draft to become an Internet Standard, they + ask the RFC Editor to publish it as a Proposed Standard. After it + has been a Proposed Standard for at least six months, the RFC's + author (or the appropriate WG chair) can ask for it to become a Draft + Standard. Before that happens, however, someone needs to convince + the appropriate Area Director that there are at least two + independent, interoperable implementations of each part of the + standard. This is a good test of the usefulness of the standard as a + whole, as well as an excellent way to check if the standard was + really readable. + + A few things typically happen at this point. First, it's common to + find that some of the specifications in the standard need to be + reworded because one implementor thought they meant one thing while + another implementor thought they meant something else. Another + common occurrence is that none of the implementations actually tried + to implement a few of the features of the standard; these features + get removed not just because no one tested them, but also because + they weren't needed. + + Don't be surprised if a particular standard doesn't progress from + Proposed to Draft. In fact, most of the standards in common use are + Proposed Standards and never move forward. This may be because no + one took the time to try to get them to Draft, or some of the + normative references in the standard are still at Proposed Standard, + or it may be that everyone found more important things to do. + + A few years after a document has been a Draft Standard, it can become + an Internet Standard, also known as "full standard." This doesn't + happen often, and is usually reserved for protocols that are + absolutely required for the Internet to function. The IESG goes over + the document with a fine-tooth comb before making a Draft Standard an + Internet Standard. + +6.4.1 Telling It Like It Is -- Using MUST and SHOULD and MAY + + Writing specifications that get implemented the way you want is a bit + of an art. You can keep the specification very short, with just a + list of requirements, but that tends to cause implementors to take + too much leeway. If you instead make the specification very wordy + with lots of suggestions, implementors tend to miss the requirements + (and often disagree with your suggestions anyway). An optimal + specification is somewhere in between. + + + + +Harris Informational [Page 27] + +RFC 3160 The Tao of IETF August 2001 + + + One way to make it more likely that developers will create + interoperable implementations of standards is to be clear about + what's being mandated in a specification. Early RFCs used all kinds + of expressions to explain what was needed, so implementors didn't + always know which parts were suggestions and which were requirements. + As a result, standards writers in the IETF generally agreed to limit + their wording to a few specific words with a few specific meanings. + + RFC 1123, "Requirements for Internet Hosts -- Application and + Support," written way back in 1989, had a short list of words that + had appeared to be useful, namely "must", "should", and "may". These + definitions were updated and further refined in BCP 14, "Key words + for use in RFCs to Indicate Requirement Levels," which is widely + referenced in current Internet standards. BCP 14 also specifically + defines "must not" and "should not", and lists a few synonyms for the + words defined. + + In a standard, in order to make it clear that you're using the + definitions from BCP 14, you should do two things. First, refer to + BCP 14 (although most people refer to it as RFC 2119, because that's + what BCP 14 tells you to do), so that the reader knows how you're + defining your words. Second, you should point out which instances of + the words you are using come from BCP 14. The accepted practice for + this is to capitalize the words. That is why you see "MUST" and + "SHOULD" capitalized in IETF standards. + + BCP 14 is a short document, and should be read by everyone who is + reading or writing IETF standards. Although the definitions of + "must" and "must not" are fairly clear, the definitions of "should" + and "should not" cause a great deal of discussion in many WGs. When + reviewing an Internet Draft, the question is often raised, "should + that sentence have a MUST or a SHOULD in it?" This is, indeed, a + very good question, because specifications shouldn't have gratuitous + MUSTs, but also should not have SHOULDs where a MUST is needed for + interoperability. This goes to the crux of the question of over- + specifying and under-specifying requirements in standards. + +6.4.2 Normative References in Standards + + One aspect of writing IETF standards that trips up many novices (and + quite a few long-time IETF folk) is the rule about how to make + "normative references" to non-IETF documents or to other RFCs in a + standard. A normative reference is a reference to a document that + must be followed in order to implement the standard. A non-normative + reference is one that is helpful to an implementor but is not needed. + As we noted above, a "MUST" specification would certainly be + normative, so any reference needed to implement the "MUST" would be + normative. A "SHOULD" or "MAY" specification is not necessarily + + + +Harris Informational [Page 28] + +RFC 3160 The Tao of IETF August 2001 + + + normative, but it could be normative based on what is being required. + There is definitely room for debate here! + + An IETF standard may make a normative reference to any other + standards-track RFC that is at the same standards level or higher, or + to any "open standard" that has been developed outside the IETF. The + "same level or higher" rule means that before a standard can move + from Proposed to Draft, all of the RFCs for which there is a + normative reference must also be at Draft or Internet Standard. This + rule gives implementors assurance that everything in a Draft Standard + or Internet Standard is quite stable, even the things referenced + outside the standard. This can also delay the publication of the + Draft or Internet Standard by many months (sometimes even years) + while the other documents catch up. + + There is no hard and fast rule about what is an "open standard," but + generally this means a stable standard that anyone can get a copy of + (although they might have to pay for it) and that was made by a + generally recognized standards group. If the external standard + changes, you have to reference the particular instantiation of that + standard in your specification, as with a designation of the date of + the standard. Some external standards bodies don't make old + standards available, which is a problem for IETF standards that need + to be used in the future. When in doubt, a draft author should ask + the WG chair or appropriate Area Director if a particular external + standard can be used in an IETF standard. + +6.4.3 IANA Considerations + + More and more IETF standards require the registration of various + protocol parameters, such as named options in the protocol. As we + noted in Section 1.2.4, the main registry for all IETF standards has + long been IANA. Because of the large and diverse kinds of registries + that standards require, IANA needs to have specific information about + how to register parameters, what not to register, who (if anyone) + will decide what is to be registered, and so on. + + Anyone writing an Internet standard that may need an IANA registry + needs to read BCP 26, "Guidelines for Writing an IANA Considerations + Section in RFCs," which describes how RFC authors should properly ask + for IANA to start or take over a registry. IANA also maintains + registries that were started long before BCP 26 was produced. + +6.4.4 Security Considerations + + One thing that's required in every RFC is a "Security Considerations" + section. This section should describe any known vulnerabilities of + the protocol, possible threats, and mechanisms or strategies to + + + +Harris Informational [Page 29] + +RFC 3160 The Tao of IETF August 2001 + + + address them. Don't gloss over this section -- in particular, don't + say "here's our protocol, if you want security, just use IPSEC". + This won't do at all, because it doesn't answer the question of how + IPSEC interacts with your protocol, and vice versa. Be sure to check + with your Working Group chair if you're not sure how to handle this + section in your draft. + +6.4.5 Patents in IETF Standards + + The problems of intellectual property have cropped up more and more + often in the past few years, particularly with respect to patents. + The goal of the IETF is to have its standards widely used and + validated in the marketplace. If creating a product that uses a + standard requires getting a license for a patent, people are less + likely to implement the standard. Not surprisingly, then, the + general rule has been "use good non-patented technology where + possible." + + Of course, this isn't always possible. Sometimes patents appear + after a standard has been established. Sometimes there's a patent on + something that is so valuable that there isn't a non-patented + equivalent. Sometimes, the patent holder is generous and promises to + give all implementors of a standard a royalty-free license to the + patent, thereby making it almost as easy to implement as it would + have been if no patent existed. + + The IETF's methods for dealing with patents in standards are a + subject of much debate. You can read about the official rules in BCP + 9, but you should assume that the application of those rules is + flexible and depends on the type of patent, the patent holder, and + the availability of alternate technologies that are not encumbered by + patents. + + Patent holders who freely allow their patents to be used by people + implementing IETF standards often get a great deal of good will from + the folks in the IETF. Such generosity is more common than you might + think. For example, RFC 1822 is a license from IBM for one of its + security patents, and the security community has responded very + favorably to IBM for this (whereas a number of other companies have + made themselves pariahs for their intractability on their security + patents). + + If you are writing an Internet Draft and you know of a patent that + applies to the technology you're writing about, don't list the patent + in the document. Instead, send a note to the IETF Secretariat + (ietf-secretariat@ietf.org) about the patent or other intellectual + property rights. The note will be published on the IETF IPR web page + (http://www.ietf.org/ipr.html). Intellectual property rights aren't + + + +Harris Informational [Page 30] + +RFC 3160 The Tao of IETF August 2001 + + + mentioned in RFCs because RFCs never change after they are published, + but knowledge of IPR can change at any time. Therefore, an IPR list + in a RFC could be incomplete and mislead the reader. BCP 9 provides + specific text that should be added to RFCs where the author knows of + IPR issues. + +6.5 Informational and Experimental RFCs + + As we noted earlier, not all RFCs are standards. In fact, plenty of + important RFCs are not on the standards track at all. Currently, + there are two designations for RFCs that are not meant to be + standards: Informational, like the Tao, and Experimental. (There is + actually a third designation, Historical, but that is reserved for + documents that were on the standards track and have been removed due + to lack of current use, or that more recent thinking indicates the + technology is actually harmful to the Internet.) + + The role of Informational RFCs is often debated in the IETF. Many + people like having them, particularly for specifications that were + created outside the IETF but are referenced by IETF documents. They + are also useful for specifications that are the precursors for work + being done by IETF Working Groups. On the other hand, some people + refer to Informational RFCs as "standards" even though the RFCs are + not standards, usually to fool the gullible public about something + that the person is selling or supporting. When this happens, the + debate about Informational RFCs is renewed. + + Experimental RFCs are for specifications that may be interesting, but + for which it is unclear if there will be much interest in + implementing them. That is, a specification might solve a problem, + but if it is not clear many people think that the problem is + important, or think that they will bother fixing the problem with the + specification, the specification might be labeled an Experimental + RFC. If, later, the specification becomes popular, it can be re- + issued as a standards-track RFC. Experimental RFCs are also used to + get people to experiment with a technology that looks like it might + be standards track material, but for which there are still unanswered + questions. + +7. How to Contribute to the IETF -- What You Can Do + + Read -- Review the Internet Drafts in your area of expertise, + and comment on them in the Working Groups. + Participate in the discussion in a friendly, helpful + fashion, with the goal being the best Internet + standards possible. Listen much more than you speak. + + + + + +Harris Informational [Page 31] + +RFC 3160 The Tao of IETF August 2001 + + + Implement -- Write programs that use the current Internet + standards. The standards aren't worth much unless + they are available to Internet users. Implement even + the "minor" standards, since they will become less + minor if they appear in more software. Report any + problems you find with the standards to the + appropriate Working Group so that the standard can be + clarified in later revisions. One of the oft-quoted + tenets of the IETF is "running code wins," so you can + help support the standards you want to become more + widespread by creating more running code. + + Write -- Edit or co-author Internet Drafts in your area of + expertise. Do this for the benefit of the Internet + community, not to get your name (or, even worse, your + company's name) on a document. Draft authors are + subject to all kinds of technical (and sometimes + personal) criticism; receive it with equanimity and + use it to improve your draft in order to produce the + best and most interoperable standard. + +7.1 What Your Company Can Do + + Share -- Avoid proprietary standards. If you are an + implementor, exhibit a strong preference for IETF + standards. If the IETF standards aren't as good as + the proprietary standards, work to make the IETF + standards better. If you're a purchaser, avoid + products that use proprietary standards that compete + with the open standards of the IETF, and tell the + companies you buy from that you are doing so. + + Open Up -- If your company controls a patent that is used in an + IETF standard, convince them to make the patent + available at no cost to everyone who is implementing + the standard. In the past few years, patents have + caused a lot of serious problems for Internet + standards because they prevent some companies from + being able to freely implement the standards. + Fortunately, many companies have generously offered + unlimited licenses for particular patents in order to + help the IETF standards flourish. These companies are + usually rewarded with positive publicity for the fact + that they are not as greedy or short-sighted as other + patent-holders. + + + + + + +Harris Informational [Page 32] + +RFC 3160 The Tao of IETF August 2001 + + + Join -- Become a member of ISOC. More importantly, urge any + company that has benefited from the Internet to become + a corporate member of ISOC, since this has the + greatest financial benefit for the group. It will, of + course, also benefit the Internet as a whole. + +8. IETF and the Outside World + +8.1 IETF and Other Standards Groups + + As much as many IETF participants would like to think otherwise, the + IETF does not exist in a standards vacuum. There are many (perhaps + too many) other standards organizations whose decisions affect the + Internet. There are also a fair number of standards bodies who + ignored the Internet for a long time and now want to get a piece of + the action. + + In general, the IETF tries to have cordial relationships with other + significant standards bodies. This isn't always easy, since many + other bodies have very different structures than the IETF, and the + IETF is mostly run by volunteers who would probably prefer to write + standards rather than meet with representatives from other bodies. + Even so, some other standards bodies make a great effort to interact + well with the IETF despite the obvious cultural differences. + + At the time of this writing, the IESG has some liaisons with large + standards bodies, including the ITU (International Telecommunication + Union), the W3C, the Unicode Consortium, the ATM Forum, and ISO- + IEC/JTC1 (The Joint Technical Committee of the International + Organization for Standardization and International Electrotechnical + Commission). The list of IETF liaisons, www.ietf.org/ietf/1iesg- + liaisons.txt, shows that there are many different liaisons to ISO- + IEC/JTC1 subcommittees. + +8.2 Press Coverage of the IETF + + Given that the IETF is one of the best-known bodies that is helping + move the Internet forward, it's natural for the computer press (and + even the trade press) to want to cover its actions. In recent years, + a small number of magazines have assigned reporters and editors to + cover the IETF in depth over a long period of time. These reporters + have ample scars from articles that they got wrong, incorrect + statements about the status of Internet Drafts, quotes from people + who are unrelated to the IETF work, and so on. + + + + + + + +Harris Informational [Page 33] + +RFC 3160 The Tao of IETF August 2001 + + + Major press errors fall into two categories: saying that the IETF is + considering something when in fact there is just an Internet Draft in + a Working Group, and saying that the IETF approved something when all + that happened was that an Informational RFC was published. In both + cases, the press is not fully to blame for the problem, since they + are usually alerted to the story by a company trying to get publicity + for a protocol that they developed or at least support. Of course, a + bit of research by the reporter would probably get them in contact + with someone who could straighten them out, such as a WG chair or an + Area Director. The official press contact for the IETF is the IETF + Secretariat. + + The fact that those reporters who've gotten it wrong once come back + to IETF meetings shows that it is possible to get it right + eventually. However, IETF meetings are definitely not for reporters + who are naive about the IETF process (although if you are a reporter + the fact that you are reading this document is a very good sign!). + Further, if you think that you'll get a hot story from attending an + IETF meeting, you are likely to be disappointed. + + Considering all this, it's not surprising that some IETFers would + prefer to have the press stay as far away from meetings as possible. + Having a bit of press publicity for protocols that are almost near + completion and will become significant in the industry in the next + year can be a good thing. However, it is the rare reporter who can + resist over-hyping a nascent protocol as the next savior for the + Internet. Such stories do much more harm than good, both for the + readers of the article and for the IETF. + + The main reason why a reporter might want to attend an IETF meeting + is not to cover hot technologies (since that can be done in the + comfort of your office by reading the mailing lists), but to meet + people face to face. Unfortunately, the most interesting people are + the ones who are also the busiest during the IETF meeting, and some + folks have a tendency to run away when they see a press badge. + However, IETF meetings are excellent places to meet and speak with + document authors and Working Group chairs; this can be quite valuable + for reporters who are covering the progress of protocols. + + Reporters who want to find out about "what the IETF is doing" on a + particular topic would be well-advised to talk to more than one + person who is active on that topic in the IETF, and should probably + try to talk to the WG chair in any case. It's impossible to + determine what will happen with a draft by looking at the draft or + talking to the draft's author. Fortunately, all WGs have archives + that a reporter can look through for recent indications about what + the progress of a draft is; unfortunately, few reporters have the + time or inclination to do this kind of research. Because the IETF + + + +Harris Informational [Page 34] + +RFC 3160 The Tao of IETF August 2001 + + + doesn't have a press liaison, a magazine or newspaper that runs a + story with errors won't hear directly from the IETF and therefore + often won't know what they did wrong, so they might easily do it + again later. + +9. References + +9.1 Tao + + Pronounced "dow", Tao is the basic principle behind the teachings of + Lao-tse, a Chinese master. Its familiar symbol is the black and + white Yin-Yang circle. Taoism conceives the universe as a single + organism, and human beings as interdependent parts of a cosmic whole. + Tao is sometimes translated "the way," but according to Taoist + philosophy the true meaning of the word cannot be expressed in words. + +9.2 Useful E-mail Addresses + + agenda@ietf.org Requests for agenda slots at IETF + meetings + ietf-info@ietf.org General questions about the IETF + ietf-registrar@ietf.org Questions about registration, meeting + locations, and fees + ietf-request@ietf.org Requests to join/leave IETF lists + ietf-secretariat@ietf.org Questions for the Secretariat + ietf-web@ietf.org Web questions/comments + internet-drafts@ietf.org Internet Draft submissions and queries + minutes@ietf.org Where to send Working Group minutes + proceedings@ietf.org IETF Proceedings Coordinator + iana@iana.org Internet Assigned Numbers Authority + rfc-ed@rfc-editor.org RFC Editor + +9.3 Useful Documents and Files + + The IETF web site, http://www.ietf.org, is the best source for + information about meetings, Working Groups, Internet Drafts, RFCs, + IETF e-mail addresses, and much more. Click on "Additional + Information" to find a variety of helpful links. Internet Drafts and + other documents are also available in the "ietf" directory on + anonymous FTP sites worldwide. For a listing of these sites, see: + + http://www.ietf.org/shadow.html + + Check the IESG web pages, http://www.ietf.org/iesg.html, to find + up-to-date information about drafts processed, RFCs published, and + documents in Last Call, as well as the monthly IETF status reports. + + + + + +Harris Informational [Page 35] + +RFC 3160 The Tao of IETF August 2001 + + +9.4 Acronyms and Abbreviations Used in the Tao + + AD Area Director + BCP Best Current Practice + BOF Birds Of a Feather + FAQ Frequently Asked Question(s) + FYI For Your Information (RFC) + IAB Internet Architecture Board + IANA Internet Assigned Numbers Authority + ICANN Internet Corporation for Assigned Names and Numbers, + http://www.icann.org/ + I-D Internet Draft + IESG Internet Engineering Steering Group, + http://www.ietf.org/iesg.html + IETF Internet Engineering Task Force, http://www.ietf.org/ + INET Internet Society Conference, + http://www.isoc.org/isoc/conferences/inet/ + IRTF Internet Research Task Force, http://www.irtf.org/ + ISO International Organization for Standardization, + http://www.iso.ch/ + ISO-IEC/JTC1 + Joint Technical Committee of the International + Organization for Standardization and International + Electrotechnical Commission, http://www.jtc1.org/ + ISOC Internet Society, http://www.isoc.org + ITU International Telecommunication Union, http://www.itu.int + RFC Request For Comments + STD Standard (RFC) + W3C World Wide Web Consortium, http://www.w3.org/ + WG Working Group + +9.5 Documents Cited in the Tao + + BCP 9 "The Internet Standards Process" + BCP 10 "IAB and IESG Selection, Confirmation, and Recall Process: + Operation of the Nominating and Recall Committees" + BCP 11 "The Organizations Involved in the IETF Standards Process" + BCP 14 "Key words for use in RFCs to Indicate Requirement Levels" + BCP 22 "Guide for Internet Standards Writers" + BCP 25 "IETF Working Group Guidelines and Procedures" + BCP 26 "Guidelines for Writing an IANA Considerations Section + in RFCs" + RFC 1123 "Requirements for Internet Hosts -- Application and + Support" + RFC 1796 "Not All RFCs are Standards" + RFC 2223 "Instructions to RFC Authors" + + + + + +Harris Informational [Page 36] + +RFC 3160 The Tao of IETF August 2001 + + + "Considerations for Internet Drafts," + http://www.ietf.org/ID-nits.html + + "Guidelines to Authors of Internet-Drafts," + ftp://ftp.ietf.org/ietf/1id-guidelines.txt + +Security Considerations + + Section 6.4.5 explains why each RFC is required to have a Security + Considerations section, and gives some idea of what it should and + should not contain. Other than that information, this document does + not touch on Internet security. + +Editor's Address + + Susan Harris + Merit Network, Inc. + 4251 Plymouth Road, Suite 2000 + Ann Arbor, MI 48105 + + EMail: srh@merit.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Harris Informational [Page 37] + +RFC 3160 The Tao of IETF August 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Harris Informational [Page 38] + |