idnits 2.17.1 draft-hoffman-tao4677bis-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC4677, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2012) is 4325 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3777 (ref. 'BCP10') (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 4071 (ref. 'BCP101') (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 2028 (ref. 'BCP11') (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'BCP26') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3005 (ref. 'BCP45') (Obsoleted by RFC 9245) -- Obsolete informational reference (is this intentional?): RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) -- Obsolete informational reference (is this intentional?): RFC 6635 (Obsoleted by RFC 8728) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Obsoletes: RFC 4677 June 2012 5 (if approved) 6 Intended status: Informational 7 Expires: December 3, 2012 9 The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force 10 draft-hoffman-tao4677bis-16 12 Abstract 14 This document describes the inner workings of IETF meetings and 15 Working Groups, discusses organizations related to the IETF, and 16 introduces the standards process. It is not a formal IETF process 17 document but instead an informational overview. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 3, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. What Is the IETF? . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Humble Beginnings . . . . . . . . . . . . . . . . . . . . 6 68 2.2. The Hierarchy . . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.1. ISOC (Internet Society) . . . . . . . . . . . . . . . 7 70 2.2.2. IESG (Internet Engineering Steering Group) . . . . . . 7 71 2.2.3. IAB (Internet Architecture Board) . . . . . . . . . . 9 72 2.2.4. IANA (Internet Assigned Numbers Authority) . . . . . . 10 73 2.2.5. RFC Editor . . . . . . . . . . . . . . . . . . . . . . 11 74 2.2.6. IETF Secretariat . . . . . . . . . . . . . . . . . . . 11 75 2.2.7. IETF Trust . . . . . . . . . . . . . . . . . . . . . . 12 76 2.3. IETF Mailing Lists . . . . . . . . . . . . . . . . . . . . 12 77 3. IETF Meetings . . . . . . . . . . . . . . . . . . . . . . . . 13 78 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 14 79 3.2. Take the Plunge and Stay All Week! . . . . . . . . . . . . 15 80 3.3. Newcomer Training . . . . . . . . . . . . . . . . . . . . 15 81 3.4. Dress Code . . . . . . . . . . . . . . . . . . . . . . . . 15 82 3.5. WG Meetings . . . . . . . . . . . . . . . . . . . . . . . 16 83 3.6. Seeing Spots Before Your Eyes . . . . . . . . . . . . . . 16 84 3.7. Terminal Room . . . . . . . . . . . . . . . . . . . . . . 17 85 3.8. Meals and Other Delights . . . . . . . . . . . . . . . . . 18 86 3.9. Social Event . . . . . . . . . . . . . . . . . . . . . . . 18 87 3.10. Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 3.11. EDU to the Rescue . . . . . . . . . . . . . . . . . . . . 19 89 3.12. Where Do I Fit In? . . . . . . . . . . . . . . . . . . . . 19 90 3.12.1. IS Managers . . . . . . . . . . . . . . . . . . . . . 19 91 3.12.2. Network Operators and ISPs . . . . . . . . . . . . . . 19 92 3.12.3. Networking Hardware and Software Vendors . . . . . . . 20 93 3.12.4. Academics . . . . . . . . . . . . . . . . . . . . . . 20 94 3.12.5. Computer Trade Press . . . . . . . . . . . . . . . . . 21 95 3.13. Proceedings . . . . . . . . . . . . . . . . . . . . . . . 21 96 3.14. Other General Things . . . . . . . . . . . . . . . . . . . 21 98 4. Working Groups . . . . . . . . . . . . . . . . . . . . . . . . 22 99 4.1. Working Group Chairs . . . . . . . . . . . . . . . . . . . 23 100 4.2. Getting Things Done in a Working Group . . . . . . . . . . 23 101 4.3. Working Group Documents . . . . . . . . . . . . . . . . . 25 102 4.4. Preparing for Working Group Meetings . . . . . . . . . . . 26 103 4.5. Working Group Mailing Lists . . . . . . . . . . . . . . . 27 104 4.6. Interim Working Group Meetings . . . . . . . . . . . . . . 28 105 5. BOFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 6. RFCs and Internet-Drafts . . . . . . . . . . . . . . . . . . . 30 107 6.1. Getting an RFC Published . . . . . . . . . . . . . . . . . 30 108 6.2. Letting Go Gracefully . . . . . . . . . . . . . . . . . . 32 109 6.3. Internet-Drafts . . . . . . . . . . . . . . . . . . . . . 33 110 6.3.1. Recommended Reading for Writers . . . . . . . . . . . 34 111 6.3.2. Filenames and Other Matters . . . . . . . . . . . . . 35 112 6.4. Standards-Track RFCs . . . . . . . . . . . . . . . . . . . 35 113 6.4.1. Telling It Like It Is -- Using MUST and SHOULD and 114 MAY . . . . . . . . . . . . . . . . . . . . . . . . . 37 115 6.4.2. Normative References in Standards . . . . . . . . . . 38 116 6.4.3. IANA Considerations . . . . . . . . . . . . . . . . . 38 117 6.4.4. Security Considerations . . . . . . . . . . . . . . . 39 118 6.4.5. Patents in IETF Standards . . . . . . . . . . . . . . 39 119 6.5. Informational and Experimental RFCs . . . . . . . . . . . 40 120 7. How to Contribute to the IETF . . . . . . . . . . . . . . . . 41 121 7.1. What You Can Do . . . . . . . . . . . . . . . . . . . . . 41 122 7.2. What Your Company Can Do . . . . . . . . . . . . . . . . . 41 123 8. IETF and the Outside World . . . . . . . . . . . . . . . . . . 42 124 8.1. IETF and Other Standards Groups . . . . . . . . . . . . . 42 125 8.2. Press Coverage of the IETF . . . . . . . . . . . . . . . . 43 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 127 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 128 11. Informative References . . . . . . . . . . . . . . . . . . . . 45 129 Appendix A. Related Information . . . . . . . . . . . . . . . . . 46 130 A.1. Why "the Tao"? . . . . . . . . . . . . . . . . . . . . . . 46 131 A.2. Useful Email Addresses . . . . . . . . . . . . . . . . . . 46 132 A.3. Useful Documents and Files . . . . . . . . . . . . . . . . 47 133 A.4. Acronyms and Abbreviations Used in the Tao . . . . . . . . 47 134 Appendix B. IETF Guiding Principles . . . . . . . . . . . . . . . 48 135 B.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 48 136 B.2. Management and Leadership . . . . . . . . . . . . . . . . 49 137 B.3. Process . . . . . . . . . . . . . . . . . . . . . . . . . 49 138 B.4. Working Groups . . . . . . . . . . . . . . . . . . . . . . 50 139 B.5. Documents . . . . . . . . . . . . . . . . . . . . . . . . 50 141 1. Introduction 143 Since its early years, attendance at Internet Engineering Task Force 144 (IETF) face-to-face meetings has grown phenomenally. Many of the 145 attendees are new to the IETF at each meeting, and many of those go 146 on to become regular attendees. When the meetings were smaller, it 147 was relatively easy for a newcomer to get into the swing of things. 148 Today, however, a newcomer meets many more new people, some 149 previously known only as the authors of documents or thought- 150 provoking email messages. 152 This document describes many aspects of the IETF, with the goal of 153 explaining to newcomers how the IETF works. This will give them a 154 warm, fuzzy feeling and enable them to make the meeting and the 155 Working Group discussions more productive for everyone. This 156 document started out fairly short, but expanded over time in response 157 to suggestions from IETF novices about what more they would have 158 wanted to know before attending their first face-to-face meeting or 159 becoming active in their first Working Group. 161 Of course, it's true that many IETF participants don't go to the 162 face-to-face meetings at all. Instead, they're active on the mailing 163 list of various IETF Working Groups. Since the inner workings of 164 Working Groups can be hard for newcomers to understand, this document 165 provides the mundane bits of information that newcomers will need in 166 order to become active participants. 168 The IETF is always in a state of change. Although the principles in 169 this document are expected to remain largely the same over time, 170 practical details may well have changed by the time you read it; for 171 example, a web-based tool may have replaced an email address for 172 requesting some sort of action. 174 Many types of IETF documentation are mentioned in the Tao, from BCPs 175 to RFCs and STDs. BCPs make recommendations for Best Current 176 Practices in the Internet; RFCs are the IETF's main technical 177 documentation series, politely known as "Requests for Comments"; and 178 STDs are RFCs identified as "standards". Actually, all three types 179 of documents are RFCs; see Section 6 for more information. 181 This document is intended to obsolete RFC 4677. See Section 2.2.5 182 for information on what it means for one RFC to obsolete another. 184 The acronyms and abbreviations used in this document are usually 185 expanded in place and are explained fully in Appendix A. 187 2. What Is the IETF? 189 The IETF is a loosely self-organized group of people who contribute 190 to the engineering and evolution of Internet technologies. It is the 191 principal body engaged in the development of new Internet standard 192 specifications. The IETF is unusual in that it exists as a 193 collection of happenings, but is not a corporation and has no board 194 of directors, no members, and no dues; see [BCP95], "A Mission 195 Statement for the IETF", for more detail. 197 Its mission includes the following: 199 o Identifying, and proposing solutions to, pressing operational and 200 technical problems in the Internet 202 o Specifying the development or usage of protocols and the near-term 203 architecture to solve such technical problems for the Internet 205 o Making recommendations to the Internet Engineering Steering Group 206 (IESG) regarding the standardization of protocols and protocol 207 usage in the Internet 209 o Facilitating technology transfer from the Internet Research Task 210 Force (IRTF) to the wider Internet community 212 o Providing a forum for the exchange of information within the 213 Internet community between vendors, users, researchers, agency 214 contractors, and network managers 216 The IETF meeting is not a conference, although there are technical 217 presentations. The IETF is not a traditional standards organization, 218 although many specifications that are produced become standards. The 219 IETF is made up of volunteers, many of whom meet three times a year 220 to fulfill the IETF mission. 222 There is no membership in the IETF. Anyone may register for a 223 meeting and then attend. The closest thing there is to being an IETF 224 member is being on the IETF or Working Group mailing lists (see 225 Section 2.3). This is where the best information about current IETF 226 activities and focus can be found. 228 Of course, no organization can be as successful as the IETF is 229 without having some sort of structure. In the IETF's case, that 230 structure is provided by other organizations, as described in 231 [BCP11], "The Organizations Involved in the IETF Standards Process". 232 If you participate in the IETF and read only one BCP, this is the one 233 you should read. 235 In many ways, the IETF runs on the beliefs of its participants. One 236 of the "founding beliefs" is embodied in an early quote about the 237 IETF from David Clark: "We reject kings, presidents and voting. We 238 believe in rough consensus and running code". Another early quote 239 that has become a commonly-held belief in the IETF comes from Jon 240 Postel: "Be conservative in what you send and liberal in what you 241 accept". 243 The IETF is really about its participants. Because the IETF welcome 244 all interested individuals, IETF participants come from all over the 245 world and from many different parts of the Internet industry. See 246 Section 3.12 for information about the ways that many people fit into 247 the IETF. 249 One more thing that is important for newcomers: the IETF in no way 250 "runs the Internet", despite what some people mistakenly might say. 251 The IETF makes voluntary standards that are often adopted by Internet 252 users, but it does not control, or even patrol, the Internet. If 253 your interest in the IETF is because you want to be part of the 254 overseers, you may be badly disappointed by the IETF. 256 2.1. Humble Beginnings 258 The first IETF meeting was held in January 1986 at Linkabit in San 259 Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in 260 October 1986, was the first that vendors attended. The concept of 261 Working Groups was introduced at the 5th IETF meeting at the NASA 262 Ames Research Center in California in February 1987. The 7th IETF, 263 held at MITRE in McLean, Virginia, in July 1987, was the first 264 meeting with more than 100 attendees. 266 The 14th IETF meeting was held at Stanford University in July 1989. 267 It marked a major change in the structure of the IETF universe. The 268 structure of the IAB (then the Internet Activities Board, now the 269 Internet Architecture Board), which until that time oversaw many 270 "task forces", was changed, leaving it with only two: the IETF and 271 the IRTF. The IRTF is tasked to consider long-term research problems 272 in the Internet. The IETF also changed at that time. 274 After the Internet Society (ISOC) was formed in January 1992, the IAB 275 proposed to ISOC that the IAB's activities should take place under 276 the auspices of the Internet Society. During INET92 in Kobe, Japan, 277 the ISOC Trustees approved a new charter for the IAB to reflect the 278 proposed relationship. 280 The IETF met in Amsterdam, The Netherlands, in July 1993. This was 281 the first IETF meeting held in Europe, and the US/non-US attendee 282 split was nearly 50/50. The IETF first met in Asia (in Adelaide, 283 Australia) in 2000. 285 Currently, the IETF meets in North America, Europe, and Asia. The 286 intention is to meet once a year in each region, although due to 287 scheduling issues there are often more meetings in North America and 288 fewer in Asia and Europe. The number of non-US attendees continues 289 to be high -- about 50%, even at meetings held in the United States. 291 2.2. The Hierarchy 293 2.2.1. ISOC (Internet Society) 295 The Internet Society is an international, non-profit, membership 296 organization that fosters the expansion of the Internet. One of the 297 ways that ISOC does this is through financial and legal support of 298 the other "I" groups described here, particularly the IETF. ISOC 299 provides insurance coverage for many of the people holding leadership 300 positions in the IETF process and acts as a public relations channel 301 for the times that one of the "I" groups wants to say something to 302 the press. The ISOC is one of the major unsung heroes of the 303 Internet. 305 Starting in spring 2005, the ISOC also became home base for the 306 IETF's directly employed administrative staff. This is described in 307 more detail in [BCP101], "Structure of the IETF Administrative 308 Support Activity (IASA)". The staff initially includes only an 309 Administrative Director (IAD) who works full-time overseeing IETF 310 meeting planning, operational aspects of support services (the 311 secretariat, IANA (the Internet Assigned Numbers Authority), and the 312 RFC Editor, which are described later in this section), and the 313 budget. He or she (currently it's a he) leads the IETF 314 Administrative Support Activity (IASA), which takes care of tasks 315 such as collecting meeting fees and paying invoices, and also 316 supports the tools for the work of IETF working groups, the IESG, the 317 IAB, and the IRTF (more about these later in this section). 319 The IETF Administrative Oversight Committee (IAOC) consists of 320 volunteers, all chosen directly or indirectly by the IETF community, 321 as well as appropriate ex officio members from ISOC and IETF 322 leadership. The IASA and the IAD are directed by the IAOC. 324 Neither the IAD nor the IAOC have any influence over IETF standards 325 development, which we turn to now. 327 2.2.2. IESG (Internet Engineering Steering Group) 329 The IESG is responsible for technical management of IETF activities 330 and the Internet standards process. It administers the process 331 according to the rules and procedures that have been ratified by the 332 ISOC Board of Trustees. However, the IESG doesn't exercise much 333 direct leadership, such as the kind you will find in many other 334 standards organizations. As its name suggests, its role is to set 335 directions rather than to give orders. The IESG ratifies or steers 336 the output from the IETF's Working Groups (WGs), gets WGs started and 337 finished, and makes sure that non-WG drafts that are about to become 338 RFCs are correct. 340 The IESG consists of the Area Directors (often called "ADs"), who are 341 selected by the Nominations Committee (which is usually called "the 342 NomCom") and are appointed for two years. The process for choosing 343 the members of the IESG is detailed in [BCP10], "IAB and IESG 344 Selection, Confirmation, and Recall Process: Operation of the 345 Nominating and Recall Committees". 347 The current Areas and abbreviations are shown below. 349 Area Description 350 ----------------------------------------------------------------- 351 Applications (APP) Protocols seen by user programs, such as 352 email and the web 354 General (GEN) IETF process, and catch-all for WGs that 355 don't fit in other Areas (which is 356 very few) 358 Internet (INT) Different ways of moving IP packets and 359 DNS information 361 Operations and Operational aspects, network monitoring, 362 Management (OPS) and configuration 364 Real-time Delay-sensitive interpersonal 365 Applications and communications 366 Infrastructure (RAI) 368 Routing (RTG) Getting packets to their destinations 370 Security (SEC) Authentication and privacy 372 Transport (TSV) Special services for special packets 374 Because the IESG has a great deal of influence on whether Internet- 375 Drafts become RFCs, many people look at the ADs as somewhat godlike 376 creatures. IETF participants sometimes reverently ask Area Directors 377 for their opinion on a particular subject. However, most ADs are 378 nearly indistinguishable from mere mortals and rarely speak from 379 mountaintops. In fact, when asked for specific technical comments, 380 the ADs may often defer to IETF participants whom they feel have more 381 knowledge than they do on that topic. 383 The ADs for a particular Area are expected to know more about the 384 combined work of the WGs in that Area than anyone else. On the other 385 hand, the entire IESG reviews each Internet-Draft that is proposed to 386 become an RFC. Any AD may record a "DISCUSS" ballot position against 387 a draft if he or she has serious concerns. If these concerns cannot 388 be resolved by discussion, an override procedure is defined such that 389 at least two IESG members must express concerns before a draft can be 390 blocked from moving forward. These procedures help ensure that an 391 AD's "pet project" doesn't make it onto the standards track if it 392 will have a negative effect on the rest of the IETF protocols and 393 that an AD's "pet peeve" cannot indefinitely block something. 395 This is not to say that the IESG never wields power. When the IESG 396 sees a Working Group veering from its charter, or when a WG asks the 397 IESG to make the WG's badly designed protocol a standard, the IESG 398 will act. In fact, because of its high workload, the IESG usually 399 moves in a reactive fashion. It eventually approves most WG requests 400 for Internet-Drafts to become RFCs, and usually only steps in when 401 something has gone very wrong. Another way to think about this is 402 that the ADs are selected to think, not to just run the process. The 403 quality of the IETF standards comes both from the review they get in 404 the Working Groups and the scrutiny that the WG review gets from the 405 ADs. 407 The IETF is run by rough consensus, and it is the IESG that judges 408 whether a WG has come up with a result that has IETF community 409 consensus. (See Section 4.2 for more information on WG consensus.) 410 Because of this, one of the main reasons that the IESG might block 411 something that was produced in a WG is that the result did not really 412 gain consensus in the IETF as a whole, that is, among all of the 413 Working Groups in all Areas. For instance, the result of one WG 414 might clash with a technology developed in a different Working Group, 415 perhaps from another Area. An important job of the IESG is to watch 416 over the output of all the WGs to help prevent IETF protocols that 417 are at odds with each other. This is why ADs are supposed to review 418 the drafts coming out of Areas other than their own. 420 2.2.3. IAB (Internet Architecture Board) 422 The IAB is responsible for keeping an eye on the "big picture" of the 423 Internet, and it focuses on long-range planning and coordination 424 among the various areas of IETF activity. The IAB stays informed 425 about important long-term issues in the Internet, and it brings these 426 topics to the attention of people it thinks should know about them. 428 IAB members pay special attention to emerging activities in the IETF. 429 When a new IETF Working Group is proposed, the IAB reviews its 430 charter for architectural consistency and integrity. Even before the 431 group is chartered, the IAB members are more than willing to discuss 432 new ideas with the people proposing them. 434 The IAB also sponsors and organizes the Internet Research Task Force 435 and convenes invitational workshops that provide in-depth reviews of 436 specific Internet architectural issues. Typically, the workshop 437 reports make recommendations to the IETF community and to the IESG. 439 The IAB also: 441 o Approves NomCom's IESG nominations 443 o Acts as the appeals board for appeals against IESG and IAOC 444 actions 446 o Oversees the RFC series through the RFC Series Oversight Committee 447 (RSOC) 449 o Approves the appointment of the IANA 451 o Acts as an advisory body to ISOC 453 o Oversees IETF liaisons with other standards bodies 455 Like the IESG, the IAB members are selected for two-year positions by 456 the NomCom and are approved by the ISOC Board of Trustees. 458 2.2.4. IANA (Internet Assigned Numbers Authority) 460 The core registrar for the IETF's activities is the IANA (see 461 http://www.iana.org). Many Internet protocols require that someone 462 keep track of protocol items that were added after the protocol came 463 out. Typical examples of the kinds of registries needed are for TCP 464 port numbers and MIME types. The IAB has designated the IANA 465 organization to perform these tasks, and the IANA's activities are 466 financially supported by ICANN, the Internet Corporation for Assigned 467 Names and Numbers. The IAB selected ICANN, and the IANA activities 468 are provided for free as specified in [RFC2860]. 470 Ten years ago, no one would have expected to see the IANA mentioned 471 on the front page of a newspaper. IANA's role had always been very 472 low key. The fact that IANA was also the keeper of the root of the 473 domain name system forced it to become a much more public entity, one 474 that was badly maligned by a variety of people who never looked at 475 what its role was. Nowadays, the IETF is generally no longer 476 involved in the IANA's domain name and IP address assignment 477 functions, which are overseen by ICANN. 479 Even though being a registrar may not sound interesting, many IETF 480 participants will testify to how important IANA has been for the 481 Internet. Having a stable, long-term repository run by careful and 482 conservative operators makes it much easier for people to experiment 483 without worrying about messing things up. IANA's founder, Jon 484 Postel, was heavily relied upon to keep things in order while the 485 Internet kept growing by leaps and bounds, and he did a fine job of 486 it until his untimely death in 1998. 488 2.2.5. RFC Editor 490 The RFC Editor edits, formats, and publishes Internet-Drafts as RFCs, 491 working in conjunction with the IESG. An important secondary role is 492 to provide one definitive repository for all RFCs (see 493 http://www.rfc-editor.org). Once an RFC is published, it is never 494 revised. If the specification it describes changes, the standard 495 will be re-published in another RFC that "obsoletes" the first. 497 One of the most popular misconceptions in the IETF community is that 498 the role of the RFC Editor is performed by IANA. Although both the 499 RFC Editor and IANA involved the same people for many years, the RFC 500 Editor is a separate job. Today, these jobs are performed by 501 separate organizations. The IAB approves the organization that will 502 act as RFC Editor and the RFC Editor's general policy. The RFC 503 Editor is funded by IASA. 505 Up through the end of 2009, the RFC Editor was a single entity. The 506 function was split by the IAB, in coordination with the IETF 507 community, into many roles that can be performed by different people 508 or organizations, led by the IAB-appointed RFC Series Editor. The 509 RFC Editor model is described in [RFC6635]. 511 2.2.6. IETF Secretariat 513 There are, in fact, a few people who are paid to maintain the IETF. 514 The IETF Secretariat provides day-to-day logistical support, which 515 mainly means coordinating face-to-face meetings and running the IETF- 516 specific mailing lists. The Secretariat is also responsible for 517 keeping the official Internet-Drafts directory up to date and 518 orderly, maintaining the IETF web site, and for helping the IESG do 519 its work. It provides various tools for use by the community and the 520 IESG. The IETF Secretariat is under contract to IASA, which in turn 521 is financially supported by the fees collected for attending the 522 face-to-face meetings. 524 2.2.7. IETF Trust 526 Near the end of 2005, the IETF Trust was set up to hold and license 527 the intellectual property of the IETF. The reason the IETF Trust was 528 set up is that someone has to hold intellectual property, and that 529 someone should be a stable, legally-identifiable entity. The IETF 530 Trustees are the same people who serve as members of the IAOC at any 531 given point in time. Few IETF participants come into contact with 532 the IETF Trust, which is a good sign that they are quietly doing 533 their job. You can find out more about the IETF trust at their web 534 site, http://trustee.ietf.org. 536 2.3. IETF Mailing Lists 538 Anyone who plans to attend an IETF meeting should join the IETF 539 announcement mailing list (see 540 https://www.ietf.org/mailman/listinfo/IETF-Announce). This is where 541 all of the meeting information, RFC announcements, and IESG Protocol 542 Actions and Last Calls are posted. People who would like to "get 543 technical" may also join the IETF general discussion list (see 544 https://www.ietf.org/mailman/listinfo/ietf). This is where 545 discussions of cosmic significance are held (Working Groups have 546 their own mailing lists for discussions related to their work). 547 Another mailing list announces each new version of every Internet- 548 Draft as it is published (see 549 https://www.ietf.org/mailman/listinfo/I-D-Announce). 551 Subscriptions to these and other IETF-run mailing lists are handled 552 by a program called "mailman". Mailman can be somewhat finicky about 553 the format of subscription messages, and sometimes interacts poorly 554 with email programs that make all email messages into HTML files. 555 Mailman will treat you well, however, if you format your messages 556 just the way it likes. 558 The IETF discussion list is unmoderated. This means that all can 559 express their opinions about issues affecting the Internet. However, 560 it is not a place for companies or individuals to solicit or 561 advertise, as noted in [BCP45], "IETF Discussion List Charter". It 562 is a good idea to read the whole RFC (it's short!) before posting to 563 the IETF discussion list. Actually, the list does have two 564 "sergeants at arms" who keep an eye open for inappropriate postings, 565 and there is a process for banning persistent offenders from the 566 list, but fortunately this is extremely rare. 568 Only the Secretariat and a small number of IETF leaders can approve 569 messages sent to the announcement list, although those messages can 570 come from a variety of people. 572 Even though the IETF mailing lists "represent" the IETF participants 573 at large, it is important to note that attending an IETF meeting does 574 not mean you'll be automatically added to either mailing list. 576 3. IETF Meetings 578 The computer industry is rife with conferences, seminars, 579 expositions, and all manner of other kinds of meetings. IETF face- 580 to-face meetings are nothing like these. The meetings, held three 581 times a year, are week-long "gatherings of the tribes" whose primary 582 goal is to reinvigorate the WGs to get their tasks done, and whose 583 secondary goal is to promote a fair amount of mixing between the WGs 584 and the Areas. The cost of the meetings is paid by the people 585 attending and by the corporate host for each meeting (if any), 586 although IASA kicks in additional funds for things such as the audio 587 broadcast of some Working Group sessions. 589 For many people, IETF meetings are a breath of fresh air when 590 compared to the standard computer industry conferences. There is no 591 exposition hall, few tutorials, and no big-name industry pundits. 592 Instead, there is lots of work, as well as a fair amount of time for 593 socializing for many participants. IETF meetings are of little 594 interest to sales and marketing folks, but of high interest to 595 engineers and developers. 597 The general flow of an IETF meeting is that it begins with tutorials 598 and an informal gathering on Sunday, and that there are WG and BoF 599 meetings Monday through Friday. WG meetings last for between 1 and 600 2.5 hours each, and some WGs have meetings multiple times during the 601 week, depending on how much work they anticipate doing. 603 There are two plenary sessions, one technical and one administrative, 604 in the evenings during the week. The technical plenary is organized 605 by the IAB and usually has one or two panels of experts on topics of 606 interest across many WGs and Areas. The administrative plenary, 607 organized by the IETF Chair, covers things like progress reports from 608 the RFC Editor and announcements of upcoming meetings. The plenaries 609 are a good time to share with the IESG and IAOC. Praise is welcome, 610 but more often concerns and gripes are raised. 612 Currently, the IETF meets in North America, Europe, and Asia, 613 approximately once a year in each region. The past few meetings have 614 had about 1,200 attendees. There have been more than 80 IETF 615 meetings so far, and a list of upcoming meetings is available on the 616 IETF web pages, http://www.ietf.org/meeting/upcoming.html. 618 Newcomers to IETF face-to-face meetings are often in a bit of shock. 619 They expect them to be like other standards bodies, or like computer 620 conferences. Fortunately, the shock wears off after a day or two, 621 and many new attendees get quite animated about how much fun they are 622 having. On the other hand, IETFers can sometimes be surprisingly 623 rude, such as talking loudly during functions when someone is 624 speaking at the microphone or pushing through a crowd to get to food 625 or drinks. This type of anti-social behavior seems to be more common 626 at IETF meetings than at computer conferences. 628 3.1. Registration 630 To attend an IETF meeting, you have to register and pay a 631 registration fee. The meeting site and advance registration are 632 announced about two months ahead of the meeting -- earlier if 633 possible. An announcement goes out via email to the IETF-announce 634 mailing list, and information is posted on the IETF web site, 635 http://www.ietf.org, that same day. 637 You can register and pay on the web before the meeting, or in person 638 at the meeting. To get a lower registration fee, you must pay by the 639 early registration deadline (about one week before the meeting). The 640 registration fee covers all of the week's meetings, the Sunday 641 evening welcome reception (cash bar), daily continental breakfasts, 642 and afternoon beverage and snack breaks. 644 Registration is open throughout the week of the meeting. However, 645 the Secretariat highly recommends that attendees arrive for early 646 registration, usually beginning at noon on Sunday and continuing 647 throughout the Sunday evening reception. The reception is a popular 648 event where you can get a small bite to eat and socialize with other 649 early arrivals. 651 It's worth noting that neither attendee names and addresses nor IETF 652 mailing lists are ever offered for sale. 654 Before you register, you see a web page titled "Note Well". You 655 should indeed read it carefully because it lays out the rules for 656 IETF intellectual property rights. 658 If you need to leave messages for other attendees, you can do so at 659 the cork boards that are often near the registration desk. These 660 cork boards will also have last-minute meeting changes and room 661 changes. 663 You can also turn in lost-and-found items to the registration desk. 664 At the end of the meeting, anything left over from the lost-and-found 665 will usually be turned over to the hotel or brought back to the 666 Secretariat's office. 668 Incidentally, the IETF registration desk is often a convenient place 669 to arrange to meet people. If someone says "meet me at 670 registration", you should clarify if they mean the IETF registration 671 desk, or the hotel registration desk. This has been a common cause 672 of missed connections. 674 3.2. Take the Plunge and Stay All Week! 676 IETF WG meetings are scheduled from Monday morning through Friday 677 afternoon. Associated non-WG meetings often take place on the 678 preceding or following weekends. It is best to plan to be present 679 the whole week, to benefit from cross-fertilization between Working 680 Groups and from corridor discussions. As noted below, the agenda is 681 fluid, and there have been many instances of participants missing 682 important sessions due to last-minute scheduling changes after their 683 travel plans were fixed. Being present the whole week is the only 684 way to avoid this annoyance. 686 If you cannot find meetings all week to interest you, you can still 687 make the most of the IETF meeting by working between sessions. Most 688 IETF attendees carry laptop computers, and it is common to see many 689 of them in the terminal room or in the hallways working during 690 meeting sessions. There is often good wireless Internet coverage in 691 many places of the meeting venue (restaurants, coffee shops, and so 692 on), so catching up on email when not in meetings is a fairly common 693 task for IETFers. 695 3.3. Newcomer Training 697 Newcomers are encouraged to attend the Newcomer's Orientation on 698 Sunday afternoon, which is especially designed for first-time 699 attendees. The orientation is organized and conducted by the IETF 700 EDU team and is intended to provide useful introductory information. 701 The session covers what all the dots on name tags mean, the structure 702 of the IETF, and many other essential and enlightening topics for new 703 IETFers. 705 Later in the afternoon is the Newcomer's Meet and Greet, which is 706 only open to newcomers and WG chairs. This is a great place to try 707 to find people knowledgeable in the areas in which you are 708 interested. Feel free to approach any WG chair, not just those in 709 your area, to either learn about their WG or to have them help find 710 you someone in yours. 712 3.4. Dress Code 714 Since attendees must wear their name tags, they must also wear shirts 715 or blouses. Pants or skirts are also highly recommended. Seriously 716 though, many newcomers are often embarrassed when they show up Monday 717 morning in suits, to discover that everybody else is wearing 718 T-shirts, jeans (shorts, if weather permits) and sandals. There are 719 those in the IETF who refuse to wear anything other than suits. 720 Fortunately, they are well known (for other reasons) so they are 721 forgiven this particular idiosyncrasy. The general rule is "dress 722 for the weather" (unless you plan to work so hard that you won't go 723 outside, in which case, "dress for comfort" is the rule!). 725 3.5. WG Meetings 727 The heart of an IETF meeting is the WG meetings themselves. 728 Different WGs chairs have very different styles, so it is impossible 729 to generalize how a WG meeting will feel. Even though nearly all WGs 730 have agendas for their meetings, some meetings stick tightly to their 731 agenda while others are run more loosely. 733 There are a few important things that are true for all WG meetings at 734 an IETF meeting. Near the beginning of the meeting, the chair will 735 pass around the "blue sheets", which are paper forms on which 736 everyone prints their name and puts their email address. These are 737 used for long-term archival purpose to show how many people came to a 738 particular meeting and, in rare cases, exactly who showed up. The 739 normal etiquette is to watch where the blue sheets came from and to 740 pass them along in the same direction. 742 When speaking in a meeting, you should always go to the microphones 743 in the room. For controversial topics, there will be a line at the 744 mic, but do not hesitate to be the first person at the mic if you 745 have a question or a contribution to the discussion. The WG chair or 746 presenter will indicate when you can speak. Although it would be 747 easier to just raise your hand from where you are sitting, the mics 748 perform a very useful task: they let the people listening remotely 749 and in the room hear your question or comment. It is also expected 750 that you will say your name at the mic so that the person taking 751 minutes will know who is speaking. 753 3.6. Seeing Spots Before Your Eyes 755 Some of the people at the IETF will have a little colored dot on 756 their name tag. A few people have more than one. These dots 757 identify people who are silly enough to volunteer to do a lot of 758 extra work. The colors have the meanings shown here. 760 Color Meaning 761 -------------------------------------- 762 Blue Working Group/BOF chair 763 Green Host group 764 Red IAB member 765 Yellow IESG member 766 Orange Nominating Committee member 767 Purple IAOC 768 Pink IRSG 769 Teal RSE 771 (Members of the press wear orange-tinted badges.) 773 Local hosts are the people who can answer questions about the 774 terminal room, restaurants, and points of interest in the area. 776 It is important that newcomers to the IETF not be afraid to strike up 777 conversations with people who wear these dots. If the IAB and IESG 778 members and Working Group and BOF chairs didn't want to talk to 779 anybody, they wouldn't be wearing the dots in the first place. Note, 780 however, that IETF meetings are usually intense times for Area 781 Directors. Talking to an AD during an IETF meeting will often lead 782 to a request to send her or him email about two weeks later. Also, 783 when you start a hallway conversation with an Area Director (or even 784 a WG chair, for that matter), it is often good to give them about 30 785 seconds of context for the discussion. 787 3.7. Terminal Room 789 One of the most important (depending on your point of view) things 790 the host does is provide Internet access for the meeting attendees. 791 In general, wireless connectivity is excellent in all the meeting 792 rooms and most common areas, and the wired connectivity is provided 793 in the terminal room. The people and companies that donate their 794 equipment, services, and time are to be heartily congratulated and 795 thanked. 797 Although preparation far in advance of the meeting is encouraged, 798 there may be some unavoidable "last minute" things that can be 799 accomplished in the terminal room. It may also be useful to people 800 who need to make trip reports or status reports while things are 801 still fresh in their minds. 803 You need to be wearing your badge in order to get into the terminal 804 room. The terminal room provides lots of power strips, lots of 805 Ethernet ports for laptops, wireless (for the people who don't need 806 Ethernet but want power), usually a printer for public use, and 807 sometimes workstations. What it doesn't provide are terminals; the 808 name is historical. The help desk in the terminal room is a good 809 place to ask questions about network failures, although they might 810 point you off to different networking staff. 812 3.8. Meals and Other Delights 814 Marshall Rose once remarked that the IETF was a place to go for "many 815 fine lunches and dinners". Although it is true that some people eat 816 very well at the IETF, they find the food on their own; lunches and 817 dinners are not included in the registration fee. The Secretariat 818 arranges for appetizers at the Sunday evening welcome reception (not 819 meant to be a replacement for dinner), continental breakfast on 820 Monday through Friday mornings (depending on the meeting venue), and 821 (best of all) cookies, brownies, fruit, and other yummies during some 822 of the afternoon breaks. These are very often paid for by the 823 meeting host or a meeting sponsor. 825 If you prefer to get out of the hotel for meals, the local host 826 usually provides a list of places to eat within easy reach of the 827 meeting site. 829 3.9. Social Event 831 Another of the most important things organized and managed by the 832 host is the IETF social event. The social event is sometimes high- 833 tech-related event, or it might be in an art museum or a reception 834 hall. Note, however, that not all IETF meetings have social events. 836 Newcomers to the IETF are encouraged to attend the social event. All 837 are encouraged to wear their name tags and leave their laptops 838 behind. The social event is designed to give people a chance to meet 839 on a social, rather than technical, level. 841 3.10. Agenda 843 The agenda for the IETF meetings is a very fluid thing. It is 844 available on the web starting a few weeks before the meeting. Small- 845 sized agendas are available for pickup at the registration desk for 846 those with good eyesight who want to keep a copy in their pocket or 847 attached to the back of their badge. Of course, "final" in the IETF 848 doesn't mean the same thing as it does elsewhere in the world. The 849 final agenda is simply the version that went to the printer. The 850 Secretariat will post agenda changes on the bulletin board near the 851 IETF registration desk (not the hotel registration desk). These late 852 changes are not capricious: they are made "just in time" as session 853 chairs and speakers become aware of unanticipated clashes. The IETF 854 is too dynamic for agendas to be tied down weeks in advance. 856 A map showing the room locations are also shown on the agenda. Room 857 assignments can change as the agenda changes. Some Working Groups 858 meet multiple times during a meeting, and every attempt is made to 859 have a Working Group meet in the same room for each session. 861 3.11. EDU to the Rescue 863 If certain aspects of the IETF still mystify you (even after you 864 finish reading the Tao), you'll want to drop in on the on-site 865 training offered by the Education (EDU) team. These informal classes 866 are designed for newcomers and seasoned IETFers alike. In addition 867 to the Newcomer Training, the EDU team offers workshops for document 868 editors and Working Group chairs, plus an in-depth security tutorial 869 that's indispensable for both novices and longtime IETF attendees. 870 EDU sessions are generally held on Sunday afternoons. You'll find 871 more about the EDU team at http://edu.ietf.org/. 873 3.12. Where Do I Fit In? 875 The IETF is different things to different people. There are many 876 people who have been very active in the IETF who have never attended 877 an IETF meeting. You should not feel obligated to come to an IETF 878 meeting just to get a feel for the IETF. The following guidelines 879 (based on stereotypes of people in various industries) might help you 880 decide whether you actually want to come and, if so, what might be 881 the best use of your time at your first meeting. 883 3.12.1. IS Managers 885 As discussed throughout this document, an IETF meeting is nothing 886 like any trade show you have attended. IETF meetings are singularly 887 bad places to go if your intention is to find out what will be hot in 888 the Internet industry next year. You can safely assume that going to 889 Working Group meetings will confuse you more than it will help you 890 understand what is happening, or will be happening, in the industry. 892 This is not to say that no one from the industry should go to IETF 893 meetings. As an IS manager, you might want to consider sending 894 specific people who are responsible for technologies that are under 895 development in the IETF. As these people read the current Internet- 896 Drafts and the traffic on the relevant Working Group lists, they will 897 get a sense of whether or not their presence would be worthwhile for 898 your company or for the Working Groups. 900 3.12.2. Network Operators and ISPs 902 Running a network is hard enough without having to grapple with new 903 protocols or new versions of the protocols with which you are already 904 dealing. If you work for the type of network that is always using 905 the very latest hardware and software, and you are following the 906 relevant Working Groups in your copious free time, you could 907 certainly find participating in the IETF valuable. A fair amount of 908 IETF work also covers many other parts of operations of ISPs and 909 large enterprises, and the input of operators is quite valuable to 910 keep this work vibrant and relevant. Many of the best operations 911 documents from the IETF come from real-world operators, not vendors 912 and academics. 914 3.12.3. Networking Hardware and Software Vendors 916 The image of the IETF being mostly ivory tower academics may have 917 been true in the past, but the jobs of typical attendees are now in 918 industry. In most areas of the IETF, employees of vendors are the 919 ones writing the protocols and leading the Working Groups, so it's 920 completely appropriate for vendors to attend. If you create Internet 921 hardware or software, and no one from your company has ever attended 922 an IETF meeting, it behooves you to come to a meeting if for no other 923 reason than to tell the others how relevant the meeting was or was 924 not to your business. 926 This is not to say that companies should close up shop during IETF 927 meeting weeks so everyone can go to the meeting. Marketing folks, 928 even technical marketing folks, are usually safe in staying away from 929 the IETF as long as some of the technical people from the company are 930 at the meeting. Similarly, it isn't required, or likely useful, for 931 everyone from a technical department to go, particularly if they are 932 not all reading the Internet-Drafts and following the Working Group 933 mailing lists. Many companies have just a few designated meeting 934 attendees who are chosen for their ability to do complete and useful 935 trip reports. In addition, many companies have internal coordination 936 efforts and a standards strategy. If a company depends on the 937 Internet for some or all of its business, the strategy should 938 probably cover the IETF. 940 3.12.4. Academics 942 IETF meetings are often excellent places for computer science folks 943 to find out what is happening in the way of soon-to-be-deployed 944 protocols. Professors and grad students (and sometimes overachieving 945 undergrads) who are doing research in networking or communications 946 can get a wealth of information by following Working Groups in their 947 specific fields of interest. Wandering into different Working Group 948 meetings can have the same effect as going to symposia and seminars 949 in your department. Researchers are also, of course, likely to be 950 interested in IRTF activities. 952 3.12.5. Computer Trade Press 954 If you're a member of the press and are considering attending IETF, 955 we've prepared a special section of the Tao just for you -- please 956 see Section 8.2. 958 3.13. Proceedings 960 IETF proceedings are compiled in the two months following each 961 meeting and are available on the web. Be sure to look through a copy 962 -- the proceedings are filled with information about IETF that you're 963 not likely to find anywhere else. For example, you'll find snapshots 964 of most WG charters at the time of the meeting, giving you a better 965 understanding of the evolution of any given effort. 967 The proceedings sometimes start with an informative (and highly 968 entertaining) message. Each volume contains the final (hindsight) 969 agenda, an IETF overview, Area and Working Group reports, and slides 970 from the protocol and technical presentations. The Working Group 971 reports and presentations are sometimes incomplete, if the materials 972 haven't been turned in to the Secretariat in time for publication. 974 An attendee list is also included, which contains names and 975 affiliations as provided on the registration form. For information 976 about obtaining copies of the proceedings, see the web listing at 977 http://www.ietf.org/meeting/proceedings.html. 979 3.14. Other General Things 981 IETFers in general are very approachable. Never be afraid to 982 approach someone and introduce yourself. Also, don't be afraid to 983 ask questions, especially when it comes to jargon and acronyms. 985 Hallway conversations are very important. A lot of very good work 986 gets done by people who talk together between meetings and over 987 lunches and dinners. Every minute of the IETF can be considered work 988 time (much to some people's dismay). 990 A side meeting (historically but often inaccurately called a "bar 991 BOF") is an unofficial get-together between WG meetings or in the 992 late evening, during which a lot of work gets done. These side 993 meetings spring up in many different places around an IETF meeting, 994 such as restaurants, coffee shops, unused hall spaces, and (if we are 995 so lucky) pools. 997 It's unwise to get between a hungry IETFer (and there isn't any other 998 kind) and coffee break brownies and cookies, no matter how 999 interesting the hallway conversation. Steve Coya, the first IETF 1000 Executive Director, often said, "Take your cookie, then step away 1001 from the table." 1003 IETFers are fiercely independent. It's safe to question opinions and 1004 offer alternatives, but don't expect an IETFer to follow orders. 1006 The IETF meetings, and the plenary session in particular, are not 1007 places for vendors to try to sell their wares. People can certainly 1008 answer questions about their company and its products, but bear in 1009 mind that the IETF is not a trade show. This does not preclude 1010 people from recouping costs for IETF-related T-shirts, buttons, and 1011 pocket protectors. 1013 There is always a "materials distribution table" near the 1014 registration desk. This desk is used to make appropriate information 1015 available to the attendees (e.g., copies of something discussed in a 1016 Working Group session, descriptions of online IETF-related 1017 information). Please check with the Secretariat before placing 1018 materials on the desk; the Secretariat has the right to remove 1019 material that he or she feels is not appropriate. 1021 If you rely on your laptop during the meeting, it is a good idea to 1022 bring an extra battery. It is not always easy to find a spare outlet 1023 in some meeting rooms, and using the wireless access can draw down 1024 your battery faster than you might expect. If you are sitting near a 1025 power-strip in a meeting room, expect to be asked to plug and unplug 1026 for others around you. Many people bring an extension cord with 1027 spare outlets, which is a good way to make friends with your neighbor 1028 in a meeting. If you need an outlet adapter, you should try to buy 1029 it in advance because the one you need is usually easier to find in 1030 your home country. 1032 4. Working Groups 1034 The vast majority of the IETF's work is done in many Working Groups; 1035 at the time of this writing, there are about 115 different WGs. 1036 [BCP25], "IETF Working Group Guidelines and Procedures", is an 1037 excellent resource for anyone participating in WG discussions. 1039 A WG is really just a mailing list with a bit of adult supervision. 1040 You "join" the WG by subscribing to the mailing list; all mailing 1041 lists are open to anyone. Anyone can post to a WG mailing list, 1042 although most lists require non-subscribers to have their postings 1043 moderated. Each Working Group has one or two (or, rarely, three) 1044 chairs. 1046 More important, each WG has a charter that the WG is supposed to 1047 follow. The charter states the scope of discussion for the Working 1048 Group, as well as its goals. The WG's mailing list and face-to-face 1049 meetings are supposed to focus on just what is in the charter and not 1050 to wander off on other "interesting" topics. Of course, looking a 1051 bit outside the scope of the WG is occasionally useful, but the large 1052 majority of the discussion should be on the topics listed in the 1053 charter. In fact, some WG charters actually specify what the WG will 1054 not do, particularly if there were some attractive but nebulous 1055 topics brought up during the drafting of the charter. The list of 1056 all WG charters makes interesting reading for folks who want to know 1057 what the different Working Groups are supposed to be doing. 1059 4.1. Working Group Chairs 1061 The role of the WG chairs is described in both [BCP11] and [BCP25]. 1063 As volunteer cat-herders, a chair's first job is to determine the WG 1064 consensus goals and milestones, keeping the charter up to date. 1065 Next, often with the help of WG secretaries or document editors, the 1066 chair must manage WG discussion, both on the list and by scheduling 1067 meetings when appropriate. Sometimes discussions get stuck on 1068 contentious points and the chair may need to steer people toward 1069 productive interaction and then declare when rough consensus has been 1070 met and the discussion is over. Sometimes chairs also manage 1071 interactions with non-WG participants or the IESG, especially when a 1072 WG document approaches publication. Chairs have responsibility for 1073 the technical and non-technical quality of WG output. As you can 1074 imagine given the mix of secretarial, interpersonal, and technical 1075 demands, some Working Group chairs are much better at their jobs than 1076 others. 1078 WG chairs are strongly advised to go to the WG leadership training 1079 that usually happens on the Sunday preceding the IETF meeting. There 1080 is also usually a WG chairs lunch mid-week during the meeting where 1081 chair-specific topics are presented and discussed. If you're 1082 interested in what they hear there, take a look at the slides at 1083 http://edu.ietf.org. 1085 4.2. Getting Things Done in a Working Group 1087 One fact that confuses many novices is that the face-to-face WG 1088 meetings are much less important in the IETF than they are in most 1089 other organizations. Any decision made at a face-to-face meeting 1090 must also gain consensus on the WG mailing list. There are numerous 1091 examples of important decisions made in WG meetings that are later 1092 overturned on the mailing list, often because someone who couldn't 1093 attend the meeting pointed out a serious flaw in the logic used to 1094 come to the decision. Finally, WG meetings aren't "drafting 1095 sessions", as they are in some other standards bodies: in the IETF, 1096 drafting is done elsewhere. 1098 Another aspect of Working Groups that confounds many people is the 1099 fact that there is no formal voting. The general rule on disputed 1100 topics is that the Working Group has to come to "rough consensus", 1101 meaning that a very large majority of those who care must agree. The 1102 exact method of determining rough consensus varies from Working Group 1103 to Working Group. Sometimes consensus is determined by "humming" -- 1104 if you agree with a proposal, you hum when prompted by the chair. 1105 Most "hum" questions come in two parts: you hum to the first part if 1106 you agree with the proposal, or you hum to the second part if you 1107 disagree with the proposal. Newcomers find it quite peculiar, but it 1108 works. It is up to the chair to decide when the Working Group has 1109 reached rough consensus. 1111 The lack of formal voting has caused some very long delays for some 1112 proposals, but most IETF participants who have witnessed rough 1113 consensus after acrimonious debates feel that the delays often result 1114 in better protocols. (And, if you think about it, how could you have 1115 "voting" in a group that invites all interested individuals to 1116 participate, and when it's impossible to count the participants?) 1117 Rough consensus has been defined in many ways; a simple version is 1118 that it means that strongly held objections must be debated until 1119 most people are satisfied that these objections are wrong. 1121 A related problem is that some people think that their proposals 1122 should be discussed in the WG even when the WG Chairs do not. For 1123 example, if the proposed work is not really part of the charter, the 1124 WG Chairs may constrain the discussion of the proposal in order to 1125 keep the WG focused on the chartered work. Individuals who think 1126 that a WG should bring up a topic that is considered off-charter by 1127 the WG Chairs can bring their concerns to the responsible AD; the AD 1128 may agree to add the topic to the charter, or that it is already 1129 covered in the charter, or that the WG Chairs are correct and that 1130 the participant should work on the proposal outside the WG. 1132 When a WG document has been fully discussed, it usually goes through 1133 Working Group Last Call (often abbreviated as "WGLC"). This is a 1134 hopefully-final time fo the WG to iron out issues. Sometimes, WGLC 1135 will bring out so many issues that there will be a second WGLC after 1136 the revisions have been incorporated. There are no formal rules for 1137 how a WGLC happens, or even if a WGLC is needed: it is up to the WG 1138 chairs. 1140 Another method that some Working Groups adopt is to have a Working 1141 Group "secretary" to handle the juggling of the documents and the 1142 changes. The secretary can run the issue tracker if there is one, or 1143 can simply be in charge of watching that all of the decisions that 1144 are made on the mailing list are reflected in newer versions of the 1145 documents. 1147 When a WG has fulfilled its charter, it is supposed to cease 1148 operations. (Most WG mailing lists continue on after a WG is closed, 1149 still discussing the same topics as the Working Group did.) In the 1150 IETF, it is a mark of success that the WG closes up because it 1151 fulfilled its charter. This is one of the aspects of the IETF that 1152 newcomers who have experience with other standards bodies have a hard 1153 time understanding. However, some WG chairs never manage to get 1154 their WG to finish, or keep adding new tasks to the charter so that 1155 the Working Group drags on for many years (or, in a few cases, 1156 decades). The output of these aging WGs is often not nearly as 1157 useful as the earlier products, and the messy results are sometimes 1158 attributed to what's called "degenerative Working Group syndrome". 1160 4.3. Working Group Documents 1162 There is an official distinction between WG drafts and independent 1163 drafts, but in practice, sometimes there is not much procedural 1164 difference. For example, many WG mailing lists also discuss 1165 independent drafts (at the discretion of the WG chair). The WG 1166 chairs get to make the decisions about which drafts will become WG 1167 drafts and who the authors or editors of those drafts will be, 1168 usually based on consultation with the WG, and sometimes with their 1169 Area Director. This process can be tricky in cases where many people 1170 want to be a draft author, but can be just as tricky when no one 1171 wants to be a draft author but the WG is charted to do some specific 1172 work. Procedures for Internet-Drafts are covered in much more detail 1173 later in this document. 1175 Some Working Groups have complex documents or a complex set of 1176 documents (or even both). Shaking all the bugs out of one or more 1177 complex documents is a daunting task. In order to help relieve this 1178 problem, some Working Groups use "issue trackers", which are online 1179 lists of the open issues with the documents, the status of the issue, 1180 proposed fixes, and so on. Using an issue tracker not only helps the 1181 WG not to forget to do something important, it helps when someone 1182 asks a question later about why something was done in a particular 1183 fashion. 1185 For Working Group documents, the document editor serves at the 1186 pleasure of the WG Chair. There are often more than one editor for 1187 Working Group documents, particularly for complex documents. The 1188 document editor is responsible for ensuring that the contents of the 1189 document accurately reflects Working Group decisions, particularly 1190 when creating a new protocol or extension; when a document editor 1191 does not follow the WG consensus, the WG Chairs will either be more 1192 forceful about getting changes that match the consensus or replace 1193 the document editor with someone more responsive to the WG. As a 1194 Working Group document is progressing, participants suggest changes 1195 on the Working Group's mail list; the editors are expected to follow 1196 the discussion and make changes when there is agreement. 1198 If a participant makes significant contributions, the document editor 1199 or chair can invite the participant to become a co-author or co- 1200 editor, although such an addition needs to be approved by the WG 1201 Chairs. Sometimes a Working Group will consider several alternatives 1202 before selecting a particular Internet-Draft as a Working Group 1203 document. A Working Group will often take ideas from several of the 1204 alternatives to create a single Working Group document; in such a 1205 case, the chair determines who will be listed as authors on the title 1206 page and who will be acknowledged as contributors in the body of the 1207 document. 1209 When a WG document is ready to progress beyond the WG, the WG Chairs 1210 will assign a "shepherd" to take over the final process. The role of 1211 the document shepherd is described in [RFC4858]. 1213 4.4. Preparing for Working Group Meetings 1215 The most important thing that everyone (newcomers and seasoned 1216 experts) should do before coming to a face-to-face meeting is to read 1217 the Internet-Drafts and RFCs ahead of time. WG meetings are 1218 explicitly not for education: they are for developing the group's 1219 documents. Even if you do not plan to say anything in the meeting, 1220 you should read, or at least skim, the group's documents before 1221 attending so you can understand what is being said. 1223 It's up to the WG chair to set the meeting agenda, usually a few 1224 weeks in advance. If you want something discussed at the meeting, be 1225 sure to let the chair know about it. The agendas for all the WG 1226 meetings are available in advance on the IETF web site, but some WG 1227 chairs are lax (if not totally negligent) about turning them in. 1229 The Secretariat only schedules WG meetings a few weeks in advance, 1230 and the schedule often changes as little as a week before the first 1231 day. If you are only coming for one WG meeting, you may have a hard 1232 time booking your flight with such little notice, particularly if the 1233 Working Group's meeting changes schedule. Be sure to keep track of 1234 the current agenda so you can schedule flights and hotels. But, when 1235 it comes down to it, you probably shouldn't be coming for just one WG 1236 meeting. It's likely that your knowledge could be valuable in a few 1237 WGs, assuming that you've read the drafts and RFCs for those groups. 1239 If you are on the agenda at a face-to-face meeting, you should 1240 probably come with a few slides prepared. But don't come with a 1241 tutorial; people are supposed to read the drafts in advance. 1242 Projectors for laptop-based presentations are available in all the 1243 meeting rooms. 1245 And here's a tip for your slides in WG or plenary presentations: 1246 don't put your company's logo on every one, even though that is a 1247 common practice outside the IETF. The IETF frowns on this kind of 1248 corporate advertising (except for the meeting sponsor in the plenary 1249 presentation), and most presenters don't even put their logo on their 1250 opening slide. The IETF is about technical content, not company 1251 boosterism. Slides are often plain black and white for legibility, 1252 with color used only when it really adds clarity. Again, the content 1253 is the most important part of the slides, not how it's presented. 1255 One thing you might find helpful, and possibly even entertaining, 1256 during Working Group sessions is to follow the running commentary on 1257 the Jabber room associated with that Working Group. The running 1258 commentary is often used as the basis for the minutes of the meeting, 1259 but it can also include jokes, sighs, and other extraneous chatter. 1260 Jabber is a free, streaming XML technology mainly used for instant 1261 messaging. You can find pointers to Jabber clients for many 1262 platforms at http://xmpp.org/xmpp-software/clients. The Jabber 1263 chatrooms have the name of the Working Group followed by 1264 "@jabber.ietf.org". Those rooms are, in fact, available year-round, 1265 not just during IETF meetings, and some are used by active Working 1266 Group participants during protocol development. 1268 4.5. Working Group Mailing Lists 1270 As we mentioned earlier, the IETF announcement and discussion mailing 1271 lists are the central mailing lists for IETF activities. However, 1272 there are many other mailing lists related to IETF work. For 1273 example, every Working Group has its own discussion list. In 1274 addition, there are some long-term technical debates that have been 1275 moved off of the IETF list onto lists created specifically for those 1276 topics. It is highly recommended that you follow the discussions on 1277 the mailing lists of the Working Groups that you wish to attend. The 1278 more work that is done on the mailing lists, the less work that will 1279 need to be done at the meeting, leaving time for cross pollination 1280 (i.e., attending Working Groups outside one's primary area of 1281 interest in order to broaden one's perspective). 1283 The mailing lists also provide a forum for those who wish to follow, 1284 or contribute to, the Working Groups' efforts, but can't attend the 1285 IETF meetings. That's why IETF procedures require all decisions to 1286 be confirmed "on the list" and you will often hear a WG chair say, 1287 "Let's take it to the list" to close a discussion. 1289 Many IETF discussion lists use either mailman or another list 1290 manager, Majordomo. They usually have a "-request" address that 1291 handles the administrative details of joining and leaving the list. 1292 (See Section 2.3 for more information on mailman.) It is generally 1293 frowned upon when such administrivia appears on the discussion 1294 mailing list. 1296 IETF discussion lists are archived. That is, all of the messages 1297 sent to the list are automatically stored on a host for anonymous 1298 HTTP or FTP access. Many such archives are listed online at 1299 ftp://ftp.ietf.org/ietf-mail-archive or they are in a web-based 1300 archive. If you don't find the list you're looking for, send a 1301 message to the list's "-request" address (not to the list itself!). 1302 The Working Group charter listings at http://datatracker.ietf.org/wg 1303 are a useful source. http://www.ietf.org/wg/concluded is a list of 1304 old, concluded WGs. 1306 Some WG lists apply size limits on messages, particularly to avoid 1307 large documents or presentations landing in everyone's mailbox. It 1308 is well worth remembering that participants do not all have broadband 1309 connections (and even those with broadband connections sometimes get 1310 their mail on slow connections when they travel), so shorter messages 1311 are greatly appreciated. Documents can be posted as Internet-Drafts; 1312 presentation material can be posted to a web site controlled by the 1313 sender or sent personally to people who ask for it. Some WGs set up 1314 special sites to hold these large documents so that senders can post 1315 there first, then just send to the list the URL of the document. 1317 4.6. Interim Working Group Meetings 1319 Working Groups sometimes hold interim meetings between IETFs. 1320 Interim meetings aren't a substitute for IETF meetings, however -- a 1321 group can't decide to skip a meeting in a location they're not fond 1322 of and meet in Cancun (or even someplace mundane) three weeks later, 1323 for example. Interim meetings require AD approval and need to be 1324 announced at least one month in advance. Location and timing need to 1325 allow fair access for all participants. Like regular IETF meetings, 1326 someone needs to take notes and the group needs to take attendance. 1327 Decisions tentatively made during an interim WG meeting still must be 1328 ratified on the mailing list. 1330 In recent years, some Working Groups have started to have "virtual 1331 interim meetings" which take place over the phone and/or online 1332 instead of face-to-face. Virtual interim meetings can be useful for 1333 getting Working Groups to pay attention to their work between the 1334 regular IETF face-to-face meetings, and have a much lower cost for 1335 attendance than face-to-face interim meetings. Virtual interim 1336 meetings have the same reporting requirements as face-to-face virtual 1337 meetings. 1339 The IESG has rules for advance notice on time and place of interim 1340 Working Group meetings, as well as reporting the results of the 1341 meetings. The purpose of these rules is to make interim meetings 1342 accessible to as many Working Group members as possible and to 1343 maintain the transparency of the Working Group process. 1345 5. BOFs 1347 In order to form a Working Group, you need a charter and someone who 1348 is able to be chair. In order to get those things, you need to get 1349 people interested so that they can help focus the charter and 1350 convince an Area Director that the project is worthwhile. A face-to- 1351 face meeting is useful for this. In fact, very few WGs get started 1352 by an Area Director; most start after a face-to-face BOF because 1353 attendees have expressed interest in the topic. 1355 A Birds of a Feather (BOF) meeting has to be approved by the Area 1356 Director in the relevant Area before it can be scheduled. If you 1357 think you really need a new WG, approach an AD informally with your 1358 proposal and see what he or she thinks. The next step is to request 1359 a meeting slot at the next face-to-face meeting. Of course, you 1360 don't need to wait for that meeting to get some work done, such as 1361 setting up a mailing list and starting to discuss a charter. 1363 BOF meetings have a very different tone than do WG meetings. The 1364 purpose of a BOF is to make sure that a good charter with good 1365 milestones can be created and that there are enough people willing to 1366 do the work needed in order to create standards. Some BOFs have 1367 Internet-Drafts already in process, whereas others start from 1368 scratch. 1370 An advantage of having a draft before the BOF is to help focus the 1371 discussion. On the other hand, having a draft might tend to limit 1372 what the other folks in the BOF want to do in the charter. It's 1373 important to remember that most BOFs are held in order to get support 1374 for an eventual Working Group, not to get support for a particular 1375 document. 1377 Many BOFs don't turn into WGs for a variety of reasons. A common 1378 problem is that not enough people can agree on a focus for the work. 1379 Another typical reason is that the work wouldn't end up being a 1380 standard -- if, for example, the document authors don't really want 1381 to relinquish change control to a WG. (We'll discuss change control 1382 later in this document.) Only two meetings of a BOF can be scheduled 1383 on a particular subject; either a WG has to form or the topic should 1384 be dropped. 1386 6. RFCs and Internet-Drafts 1388 If you're a new IETF participant and are looking for a particular RFC 1389 or Internet-Draft, go to the RFC Editor's web pages, 1390 http://www.rfc-editor.org/rfc.html. That site also has links to 1391 other RFC collections, many with search capabilities. If you know 1392 the number of the RFC you're looking for, go to the RFC Editor's RFC 1393 pages, http://www.rfc-editor.org/rfc.html. For Internet-Drafts, a 1394 good resource is the IETF web site, https://datatracker.ietf.org/doc, 1395 where you can search by title and keyword. 1397 6.1. Getting an RFC Published 1399 One of the most common questions seasoned IETFers hear from newcomers 1400 is, "How do I get an IETF standard published?" A much better 1401 question is, "Should I write an IETF standard?" since the answer is 1402 not always "yes". If you do decide to try to write a document that 1403 becomes an IETF standard, be warned that the overall process may be 1404 arduous, even if the individual steps are fairly straightforward. 1405 Lots of people get through the process unscathed, though, and there's 1406 plenty of written guidance that helps authors emerge with their ego 1407 more or less intact. 1409 One of the first things you must decide is whether you want your 1410 document to be considered in a Working Group, of you want it to be 1411 considered as an individual (that is, non-WG) submission to the IETF. 1412 Even though most IETF standards come from Working Groups, some are 1413 individual efforts: there might be no appropriate Working Group, or a 1414 potentially-appropriate Working Group might be to busy on other work 1415 to consider your idea. 1417 Every IETF standard is published as an RFC ("Request for Comments"), 1418 and every RFC starts out as an Internet-Draft (often called an "I-D" 1419 or just "draft"). The basic steps for getting something published as 1420 an IETF standard are as follows: 1422 1. Publish the document as an Internet-Draft. 1424 2. Receive comments on the draft. 1426 3. Edit your draft based on the comments. 1428 4. Repeat steps 1 through 3 a few times. 1430 5. Ask an Area Director to take the draft to the IESG (if it's an 1431 individual submission). If the draft is an official Working 1432 Group product, the WG chair asks the AD to take it to the IESG. 1434 6. If the Area Director accepts the submission, they will do their 1435 own initial review, and maybe ask for updates before they move it 1436 forwards. 1438 7. Get reviews from the wider IETF membership. In particular, some 1439 of the Areas in the IETF have formed review teams to look over 1440 drafts that are ready to go to the IESG. Two of the more active 1441 review teams are from the Security Directorate ("SecDir") and the 1442 General Area Review Team (Gen-Art). Remember that all these 1443 reviews can help improve the quality of the eventual RFC. 1445 8. Discuss concerns with the IESG members. Their concerns might be 1446 resolved with a simple answer, or they might require additions or 1447 changes to the document. 1449 9. Wait for the document to be published by the RFC Editor. 1451 A much more complete explanation of these steps is contained in 1452 [BCP9], "The Internet Standards Process". Those who write drafts 1453 that they hope will become IETF standards must read BCP 9 so that 1454 they can follow the path of their document through the process. You 1455 can follow the progress on the IETF Datatracker 1456 http://datatracker.ietf.org. BCP 9 (and various other documents that 1457 update it) goes into great detail on a topic that is very often 1458 misunderstood, even by seasoned IETF participants: different types of 1459 RFCs go through different processes and have different rankings. 1460 There are six kinds of RFCs: 1462 o Proposed standards 1464 o Internet standards (sometimes called "full standards") 1466 o Best current practices (BCP) documents 1468 o Informational documents 1470 o Experimental documents 1472 o Historic documents 1474 Only the first two, proposed and full, are standards within the IETF. 1475 A good summary of this can be found in the aptly titled [RFC1796], 1476 "Not All RFCs Are Standards". 1478 There are also two sub-series of RFCs, known as BCPs and STDs. Best 1479 Current Practice documents describe the application of various 1480 technologies in the Internet, and are also commonly used to document 1481 the many parts of the IETF process. The sub-series of FYIs are 1482 comprised of "Informational documents" in the sense of the 1483 enumeration above, with special tagging applied. (There was also a 1484 "For Your Information" RFC sub-series that was created to document 1485 overviews and topics that are introductory or that appeal to a broad 1486 audience; however, that series has been officially closed.) 1488 The STD RFC sub-series was created to identify RFCs that do in fact 1489 specify Internet standards. Some STDs are actually sets of more than 1490 one RFC, and the "standard" designation applies to the whole set of 1491 documents. 1493 6.2. Letting Go Gracefully 1495 The biggest reason some people do not want their documents put on the 1496 IETF standards track is that they must give up change control of the 1497 protocol. That is, as soon as you propose that your protocol become 1498 an IETF standard, you must fully relinquish control of the protocol. 1499 If there is general agreement, parts of the protocol can be 1500 completely changed, whole sections can be ripped out, new things can 1501 be added, and the name can be changed. 1503 Some authors find it very hard to give up control of their pet 1504 protocol. If you are one of those people, don't even think about 1505 trying to get your protocol to become an IETF standard. On the other 1506 hand, if your goal is the best standard possible with the widest 1507 implementation, then you might find the IETF process to your liking. 1509 Incidentally, the change control on Internet standards doesn't end 1510 when the protocol is put on the standards track. The protocol itself 1511 can be changed later for a number of reasons, the most common of 1512 which is that implementors discover a problem as they implement the 1513 standard. These later changes are also under the control of the 1514 IETF, not the editors of the standards document. 1516 IETF standards exist so that people will use them to write Internet 1517 programs that interoperate. They don't exist to document the 1518 (possibly wonderful) ideas of their authors, nor do they exist so 1519 that a company can say, "We have an IETF standard". If a standards- 1520 track RFC only has one implementation (whereas two are required for 1521 it to advance on the standards track), it was probably a mistake to 1522 put it on the standards track in the first place. 1524 Note that new authors cannot take someone else's document and pass it 1525 off as their own; see [BCP78], section 5.6, point (a). 1527 6.3. Internet-Drafts 1529 First things first. Every document that ends up in the RFC 1530 repository starts life as an Internet-Draft. Internet-Drafts are 1531 tentative documents -- they're meant for readers to comment on, so 1532 authors can mull over those comments and decide which ones to 1533 incorporate in the draft. In order to remind folks of their 1534 tentativeness, Internet-Drafts are automatically removed from the 1535 active online directories after six months. They are most definitely 1536 not standards. As [BCP9] says: 1538 "An Internet-Draft is NOT a means of 'publishing' a specification; 1539 specifications are published through the RFC mechanism.... Internet- 1540 Drafts have no formal status, and are subject to change or removal at 1541 any time. Under no circumstances should an Internet-Draft be 1542 referenced by any paper, report, or Request-for-Proposal, nor should 1543 a vendor claim compliance with an Internet-Draft". 1545 You can always tell a person who doesn't understand the IETF (or is 1546 intentionally trying to fool people) when he or she brags about 1547 having published an Internet-Draft; it takes no significant effort. 1549 When you submit an Internet-Draft, you give some publication rights 1550 to the IETF. This is so that your Internet-Draft is freely available 1551 to everyone who wants to read and comment on it. The rights you do 1552 and don't give to the IETF are described in [BCP78], "IETF Rights in 1553 Contributions". 1555 There is a very useful checking tool at 1556 http://tools.ietf.org/tools/idnits. Using this tool before you turn 1557 in an Internet-Draft will help prevent the draft from being rejected 1558 due to errors in form and formatting. 1560 An I-D should have approximately the same format as an RFC. Contrary 1561 to many people's beliefs, an I-D does not need to look exactly like 1562 an RFC, but if you can use the same formatting procedures used by the 1563 RFC Editor when you create your I-Ds, it will simplify the RFC 1564 Editor's work when your draft is published as an RFC. [RFC2223], 1565 "Instructions to RFC Authors", describes the submission format. 1566 There is also a tool called "xml2rfc", available from 1567 http://xml.resource.org, that takes XML-formatted text and turns it 1568 into a valid Internet-Draft. 1570 An Internet-Draft can be either a Working Group draft or an 1571 individual submission. Working Group drafts are usually reviewed by 1572 the Working Group before being accepted as a WG item, although the 1573 chairs have the final say. 1575 If you're interested in checking the status of a particular draft, or 1576 can't remember its exact name, or want to find out which drafts a WG 1577 is working on, two handy tools are available. The "Internet-Drafts 1578 Database Interface", at https://datatracker.ietf.org/doc, lets you 1579 search for a draft by author, Working Group, date, or filename. This 1580 is especially useful for authors who want to track the progress of 1581 their draft as it makes its way through the publication process. 1583 There are some informal rules for Internet-Draft naming that have 1584 evolved over the years. Internet-Drafts that revise existing RFCs 1585 often have draft names with "bis" in them, meaning "again" or 1586 "twice"; for example, a draft might be called 1587 "draft-someone-rfc2345bis-00.txt". 1589 6.3.1. Recommended Reading for Writers 1591 Before you create the first draft of your Internet-Draft, you should 1592 read four documents: 1594 o More important than just explaining formatting, [RFC2223] also 1595 explains what needs to be in an Internet-Draft before it can 1596 become an RFC. This document describes all the sections and 1597 notices that will need to be in your document, and it's good to 1598 have them there from the beginning so that readers aren't 1599 surprised when you put them in later versions. 1601 o [BCP22], "Guide for Internet Standards Writers", provides tips 1602 that will help you write a standard that leads to 1603 interoperability. For instance, it explains how to choose the 1604 right number of protocol options, how to respond to out-of-spec 1605 behavior, and how to show state diagrams. 1607 o The online "Guidelines to Authors of Internet-Drafts", 1608 http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date 1609 information about the process for turning in Internet-Drafts, as 1610 well as the most current boilerplate information that has to be 1611 included in each Internet-Draft. 1613 o When you think you are finished with the draft process and are 1614 ready to request that the draft become an RFC, you should 1615 definitely read "Checklist for Internet-Drafts (I-Ds) Submitted 1616 for RFC Publication", http://www.ietf.org/ID-Checklist.html, a 1617 list of common issues that have been known to stop documents in 1618 the IESG. In fact, you should probably read that document well 1619 before you are finished, so that you don't have to make a bunch of 1620 last-minute changes. 1622 Also, you should visit the IETF Tools web pages, 1623 http://tools.ietf.org, where you'll find pointers to other tools that 1624 will automate some of your work for the IETF. 1626 6.3.2. Filenames and Other Matters 1628 When you're ready to turn in your Internet-Draft, you submit it to 1629 http://datatracker.ietf.org/submit. The instructions on that web 1630 page will walk you through the needed steps, and there is also an 1631 email address there in case you need personalized help. 1633 When you submit the first version of the draft, you also tell the 1634 draft administrator your proposed filename for the draft. If the 1635 draft is an official Working Group product, the name will start with 1636 "draft-ietf-" followed by the designation of the WG, followed by a 1637 descriptive word or two, followed by "00.txt". 1639 For example, a draft in the S/MIME WG about creating keys might be 1640 named "draft-ietf-smime-keying-00.txt". If it's not the product of a 1641 Working Group, the name will start with "draft-" and the last name of 1642 one of the authors followed by a descriptive word or two, followed by 1643 "00.txt". For example, a draft that someone named Smith wrote might 1644 be named "draft-smith-keying-00.txt". If a draft is an individual 1645 submission but relates to a particular Working Group, authors 1646 sometimes follow their name with the name of the Working Group, such 1647 as "draft-smith-smime-keying-00.txt". If you follow the naming 1648 guidelines given at http://www.ietf.org/ietf/1id-guidelines.txt, 1649 chances are quite good that your suggested filename will be fine. 1651 After the first edition of a draft, the number in the filename is 1652 incremented; for instance, the second edition of the S/MIME draft 1653 named above would be "draft-ietf-smime-keying-01.txt". Note that 1654 there are cases where the filename changes after one or more 1655 versions, such as when a personal effort is pulled into a Working 1656 Group; when a draft has its filename changed, the number reverts to 1657 -00. The WG chairs will let the Internet-Drafts administrator know 1658 the previous name of the draft when such a name change occurs so that 1659 the databases can be kept accurate. 1661 6.4. Standards-Track RFCs 1663 The procedure for creating and advancing a standard is described in 1664 [BCP9]. After an Internet-Draft has been sufficiently discussed and 1665 there is rough consensus that what it says would be a useful 1666 standard, it is presented to the IESG for consideration. If the 1667 draft is an official WG draft, the WG chair sends it to the 1668 appropriate Area Director. If the draft is an individual submission, 1669 the draft's author or editor submits it to the appropriate Area 1670 Director. BCP 9 also describes the appeals process for people who 1671 feel that a Working Group chair, an AD, or the IESG has made the 1672 wrong decision in considering the creation or advancement of a 1673 standard. 1675 After the I-D is submitted to the IESG, the IESG announces an IETF- 1676 wide Last Call (often abbreviated as "LC"). This helps get the 1677 attention of people who weren't following the progress of the draft, 1678 and can sometimes cause further changes to the draft. It is also a 1679 time when people in the WG who feel that they weren't heard can make 1680 their comments to everyone. The IETF Last Call is at least two weeks 1681 for drafts coming from WGs and four weeks for individual submissions. 1683 The purpose of IETF Last Call is to get community-wide discussion on 1684 documents before the IESG considers them. Note the word "discussion" 1685 here. It is generally considered bad form to send IETF Last Call 1686 comments on documents that you have not read, or to send comments but 1687 not be prepared to discuss your views. The IETF Last Call is not a 1688 vote, and campaigns aimed at getting people to send support or 1689 opposition to a document usually backfire. Having said that, IETF 1690 Last Call comments that come from people who have just read the 1691 document for the first time can expose issues that IETF and WG 1692 regulars may have completely missed, which is why the discussion is 1693 open to everyone. 1695 If the IESG approves the draft to become a standards-track RFC, they 1696 ask the RFC Editor to publish it as a Proposed standard. A few 1697 things typically happen at this point. First, it's common to find 1698 that some of the specifications in the standard need to be reworded 1699 because one implementor thought they meant one thing whereas another 1700 implementor thought they meant something else. Another common 1701 occurrence is that none of the implementations actually tried to 1702 implement a few of the features of the standard; these features get 1703 removed not just because no one tested them but also because they 1704 weren't needed. 1706 Don't be surprised if a particular standard doesn't progress from 1707 Proposed Standard to Internet Standard. To become an Internet 1708 Standard, an RFC must have multiple interoperable implementations and 1709 the unused features in the Proposed Standard must be removed; there 1710 are additional requirements listed in [BCP9]. Most of the standards 1711 in common use are Proposed standards and never move forward. This 1712 may be because no one took the time to try to get them to Internet 1713 Standard, or some of the normative references in the standard are 1714 still at Proposed standard, or it may be that everyone found more 1715 important things to do. 1717 6.4.1. Telling It Like It Is -- Using MUST and SHOULD and MAY 1719 Writing specifications that get implemented the way you want is a bit 1720 of an art. You can keep the specification very short, with just a 1721 list of requirements, but that tends to cause implementors to take 1722 too much leeway. If you instead make the specification very wordy 1723 with lots of suggestions, implementors tend to miss the requirements 1724 (and often disagree with your suggestions anyway). An optimal 1725 specification is somewhere in between. 1727 One way to make it more likely that developers will create 1728 interoperable implementations of standards is to be clear about 1729 what's being mandated in a specification. Early RFCs used all kinds 1730 of expressions to explain what was needed, so implementors didn't 1731 always know which parts were suggestions and which were requirements. 1732 As a result, standards writers in the IETF generally agreed to limit 1733 their wording to a few specific words with a few specific meanings. 1735 [STD3], "Requirements for Internet Hosts -- Application and Support", 1736 written way back in 1989, had a short list of words that had appeared 1737 to be useful, namely, "must", "should", and "may". These definitions 1738 were updated and further refined in [BCP14], "Key words for use in 1739 RFCs to Indicate Requirement Levels", which is widely referenced in 1740 current Internet standards. BCP 14 also specifically defines "must 1741 not" and "should not", and it lists a few synonyms for the words 1742 defined. 1744 In a standard, in order to make it clear that you're using the 1745 definitions from BCP 14, you should do two things. First, refer to 1746 BCP 14 (although most people refer to it as RFC 2119, because that's 1747 what BCP 14 tells you to do), so that the reader knows how you're 1748 defining your words. Second, you should point out which instances of 1749 the words you are using come from BCP 14. The accepted practice for 1750 this is to capitalize the words. That is why you see "MUST" and 1751 "SHOULD" capitalized in IETF standards. 1753 BCP 14 is a short document, and it should be read by everyone who is 1754 reading or writing IETF standards. Although the definitions of 1755 "must" and "must not" are fairly clear, the definitions of "should" 1756 and "should not" cause a great deal of discussion in many WGs. When 1757 reviewing an Internet-Draft, the question is often raised, "Should 1758 that sentence have a MUST or a SHOULD in it?" This is, indeed, a 1759 very good question, because specifications shouldn't have gratuitous 1760 MUSTs, but also should not have SHOULDs where a MUST is needed for 1761 interoperability. This goes to the crux of the question of over- 1762 specifying and under-specifying requirements in standards. 1764 6.4.2. Normative References in Standards 1766 One aspect of writing IETF standards that trips up many novices (and 1767 quite a few long-time IETF folks) is the rule about how to make 1768 "normative references" to non-IETF documents or to other RFCs in a 1769 standard. A normative reference is a reference to a document that 1770 must be followed in order to implement the standard. A non-normative 1771 reference (sometimes called an "informative reference") is one that 1772 is helpful to an implementor but is not needed. 1774 An IETF standard may make a normative reference to any other 1775 standards-track RFC that is at the same standards level or higher, or 1776 to any "open standard" that has been developed outside the IETF. The 1777 "same level or higher" rule means that before a standard can move 1778 from Proposed to Draft, all of the RFCs for which there is a 1779 normative reference must also be at Draft or Internet standard. This 1780 rule is described in [BCP97]. This rule gives implementors assurance 1781 that everything in a Internet standard is quite stable, even the 1782 things referenced outside the standard. This can also delay the 1783 publication of the Draft or Internet standard by many months 1784 (sometimes even years) while the other documents catch up. 1786 There is no hard-and-fast rule about what is an "open standard", but 1787 generally this means a stable standard that anyone can get a copy of 1788 (although they might have to pay for it) and that was made by a 1789 generally recognized standards group. If the external standard 1790 changes, you have to reference the particular instantiation of that 1791 standard in your specification, as with a designation of the date of 1792 the standard. Some external standards bodies don't make old 1793 standards available, which is a problem for IETF standards that need 1794 to be used in the future. When in doubt, a draft author should ask 1795 the WG chair or appropriate Area Director if a particular external 1796 standard can be used in an IETF standard. 1798 6.4.3. IANA Considerations 1800 More and more IETF standards require the registration of various 1801 protocol parameters, such as named options in the protocol. As we 1802 noted in Section 2.2.4, the main registry for all IETF standards has 1803 long been IANA. Because of the large and diverse kinds of registries 1804 that standards require, IANA needs to have specific information about 1805 how to register parameters, what not to register, who (if anyone) 1806 will decide what is to be registered, and so on. 1808 Anyone writing an Internet standard that may need a new IANA registry 1809 or new values in a current IANA registry needs to read [BCP26], 1810 "Guidelines for Writing an IANA Considerations Section in RFCs", 1811 which describes how RFC authors should properly ask for IANA to start 1812 or take over a registry. IANA also maintains registries that were 1813 started long before BCP 26 was produced. 1815 6.4.4. Security Considerations 1817 One thing that's required in every RFC and Internet-Draft is a 1818 "Security Considerations" section. This section should describe any 1819 known vulnerabilities of the protocol, possible threats, and 1820 mechanisms or strategies to address them. Don't gloss over this 1821 section -- in particular, don't say, "Here's our protocol, if you 1822 want security, just use IPsec". This won't do at all, because it 1823 doesn't answer the question of how IPsec interacts with your 1824 protocol, and vice versa. See [BCP72], "Guidelines for Writing RFC 1825 Text on Security Considerations", for more information on writing 1826 good security considerations sections. 1828 6.4.5. Patents in IETF Standards 1830 The problems of intellectual property have cropped up more and more 1831 often in the past few years, particularly with respect to patents. 1832 The goal of the IETF is to have its standards widely used and 1833 validated in the marketplace. If creating a product that uses a 1834 standard requires getting a license for a patent, people are less 1835 likely to implement the standard. Not surprisingly, then, the 1836 general rule has been "use good non-patented technology where 1837 possible". 1839 Of course, this isn't always possible. Sometimes patents appear 1840 after a standard has been established. Sometimes there's a patent on 1841 something that is so valuable that there isn't a non-patented 1842 equivalent. Sometimes the patent holder is generous and promises to 1843 give all implementors of a standard a royalty-free license to the 1844 patent, thereby making it almost as easy to implement as it would 1845 have been if no patent existed. 1847 The IETF's methods for dealing with patents in standards are a 1848 subject of much debate. The official rules for all intellectual 1849 property rights (IPR) in IETF documents (not just patents) are 1850 covered in [BCP78] and [BCP79], "Intellectual Property Rights in IETF 1851 Technology". Everyone who participates in IETF Working Groups will 1852 probably find these documents interesting because they lay out the 1853 rules that everyone agrees to follow. 1855 Patent holders who freely allow their patents to be used by people 1856 implementing IETF standards often get a great deal of goodwill from 1857 the folks in the IETF. Such generosity is more common than you might 1858 think. For example, RFC 1822 is a license from IBM for one of its 1859 security patents in a particular protocol context, and the security 1860 community has responded very favorably to IBM for this (whereas a 1861 number of other companies have made themselves pariahs for their 1862 intractability on their security patents). 1864 If you are writing an Internet-Draft and you know of a patent that 1865 applies to the technology you're writing about, don't list the patent 1866 in the document. Instead, consult the IETF IPR page at 1867 http://www.ietf.org/ipr to determine how to proceed. Intellectual 1868 property rights aren't mentioned in RFCs because RFCs never change 1869 after they are published, but knowledge of IPR can change at any 1870 time. Therefore, an IPR list in an RFC could be incomplete and 1871 mislead the reader. [BCP79] provides specific text that should be 1872 added to RFCs where the author knows of IPR issues. 1874 6.5. Informational and Experimental RFCs 1876 As we noted earlier, not all RFCs are standards. In fact, plenty of 1877 important RFCs are not on the standards track at all. Currently, 1878 there are two designations for RFCs that are not meant to be 1879 standards: Informational, like the Tao, and Experimental. (There is 1880 actually a third designation, Historic, but that is reserved for 1881 documents that were on the standards track and have been removed due 1882 to lack of current use, or that more recent thinking indicates the 1883 technology is actually harmful to the Internet.) 1885 The role of Informational RFCs is often debated in the IETF. Many 1886 people like having them, particularly for specifications that were 1887 created outside the IETF but are referenced by IETF documents. They 1888 are also useful for specifications that are the precursors for work 1889 being done by IETF Working Groups. On the other hand, some people 1890 refer to Informational RFCs as "standards" even though the RFCs are 1891 not standards, usually to fool the gullible public about something 1892 that the person is selling or supporting. When this happens, the 1893 debate about Informational RFCs is renewed. 1895 Experimental RFCs are for specifications that may be interesting, but 1896 for which it is unclear if there will be much interest in 1897 implementing them, or whether they will work once deployed. That is, 1898 a specification might solve a problem, but if it is not clear that 1899 many people think that the problem is important, or think that they 1900 will bother fixing the problem with the specification, the 1901 specification might be labeled an Experimental RFC. If, later, the 1902 specification becomes popular (or proves that it works well), it can 1903 be re-issued as a standards-track RFC. Experimental RFCs are also 1904 used to get people to experiment with a technology that looks like it 1905 might be standards-track material, but for which there are still 1906 unanswered questions. 1908 The IESG has created guidelines on how it chooses between 1909 Informational and Experimental status: 1910 http://www.ietf.org/iesg/informational-vs-experimental.html. If you 1911 are creating a document that you think might become an Experimental 1912 RFC, knowing the current thinking will help you justify your proposed 1913 choice. 1915 7. How to Contribute to the IETF 1917 7.1. What You Can Do 1919 *Read* -- Review the Internet-Drafts in your area of expertise and 1920 comment on them in the Working Groups. Participate in the discussion 1921 in a friendly, helpful fashion, with the goal being the best Internet 1922 standards possible. Listen much more than you speak. If you 1923 disagree, debate the technical issues: never attack the people. 1925 *Implement* -- Write programs that use the current Internet 1926 standards. The standards aren't worth much unless they are available 1927 to Internet users. Implement even the "minor" standards, since they 1928 will become less minor if they appear in more software. Report any 1929 problems you find with the standards to the appropriate Working Group 1930 so that the standard can be clarified in later revisions. One of the 1931 oft-quoted tenets of the IETF is "running code wins", so you can help 1932 support the standards you want to become more widespread by creating 1933 more running code. You can help the development of protocols before 1934 they become standards by implementing (but not deploying) from I-Ds 1935 to ensure that the authors have done a good job. If you find errors 1936 or omissions, offer improvements based on your implementation 1937 experience. 1939 *Write* -- Edit or co-author Internet-Drafts in your area of 1940 expertise. Do this for the benefit of the Internet community, not to 1941 get your name (or, even worse, your company's name) on a document. 1942 Draft authors are subject to all kinds of technical (and sometimes 1943 personal) criticism; receive it with equanimity and use it to improve 1944 your draft in order to produce the best and most interoperable 1945 standard. 1947 7.2. What Your Company Can Do 1949 *Share* -- Avoid proprietary standards. If you are an implementor, 1950 exhibit a strong preference for IETF standards. If the IETF 1951 standards aren't as good as the proprietary standards, work to make 1952 the IETF standards better. If you're a purchaser, avoid products 1953 that use proprietary standards that compete with the open standards 1954 of the IETF and tell the companies you buy from that you are doing 1955 so. 1957 *Open Up* -- If your company controls a patent that is used in an 1958 IETF standard, convince the company to make the patent available at 1959 no cost to everyone who is implementing the standard. In the past 1960 few years, patents have caused a lot of serious problems for Internet 1961 standards because they prevent some companies from being able to 1962 freely implement the standards. Fortunately, many companies have 1963 generously offered unlimited licenses for particular patents in order 1964 to help the IETF standards flourish. These companies are usually 1965 rewarded with positive publicity for the fact that they are not as 1966 greedy or short-sighted as other patent-holders. 1968 *Join* -- Become a member of ISOC. More important, urge any company 1969 that has benefited from the Internet to become a corporate member of 1970 ISOC, since this has the greatest financial benefit for the group. 1971 It will, of course, also benefit the Internet as a whole. 1973 8. IETF and the Outside World 1975 8.1. IETF and Other Standards Groups 1977 As much as many IETF participants would like to think otherwise, the 1978 IETF does not exist in a standards vacuum. There are many (perhaps 1979 too many) other standards organizations whose decisions affect the 1980 Internet. There are also a fair number of standards bodies that 1981 ignored the Internet for a long time and now want to get a piece of 1982 the action. 1984 In general, the IETF tries to have cordial relationships with other 1985 standards bodies. This isn't always easy, since many other bodies 1986 have very different structures than the IETF does, and the IETF is 1987 mostly run by volunteers who would probably prefer to write standards 1988 rather than meet with representatives from other bodies. Even so, 1989 some other standards bodies make a great effort to interact well with 1990 the IETF despite the obvious cultural differences. 1992 At the time of this writing, the IETF has some liaisons with large 1993 standards bodies, including the ITU-T (the Telecommunication 1994 Standardization Sector of the International Telecommunication Union), 1995 the W3C (World Wide Web Consortium), the IEEE (the Institute of 1996 Electrical and Electronics Engineers), and the Unicode Consortium. 1997 As stated in the IAB Charter [BCP39], "Liaisons are kept as informal 1998 as possible and must be of demonstrable value in improving the 1999 quality of IETF specifications". In practice, the IETF prefers 2000 liaisons to take place directly at Working Group level, with formal 2001 relationships and liaison documents in a backup role. 2003 Some of these liaison tasks fall to the IESG, whereas others fall to 2004 the IAB. Detail-oriented readers will learn much about the formal 2005 methods for dealing with other standards bodies in [BCP102], "IAB 2006 Processes for Management of IETF Liaison Relationships", and 2007 [BCP103], "Procedures for Handling Liaison Statements to and from the 2008 IETF". The best place to check to see whether the IETF has any 2009 formal liaison at all is the list of IETF liaisons, 2010 http://www.ietf.org/liaison. The list shows that there are many 2011 different liaisons to ISO/IEC JTC1 subcommittees. 2013 8.2. Press Coverage of the IETF 2015 Given that the IETF is one of the best-known bodies that is helping 2016 move the Internet forward, it's natural for the computer press (and 2017 even the trade press) to want to cover its actions. In recent years, 2018 a small number of magazines have assigned reporters and editors to 2019 cover the IETF in depth over a long period of time. These reporters 2020 have ample scars from articles that they got wrong, incorrect 2021 statements about the status of Internet-Drafts, quotes from people 2022 who are unrelated to the IETF work, and so on. 2024 Major press errors fall into two categories: saying that the IETF is 2025 considering something when in fact there is just an Internet-Draft in 2026 a Working Group, and saying that the IETF approved something when all 2027 that happened was that an Informational RFC was published. In both 2028 cases, the press is not fully to blame for the problem, since they 2029 are usually alerted to the story by a company trying to get publicity 2030 for a protocol that they developed or at least support. Of course, a 2031 bit of research by the reporters would probably get them in contact 2032 with someone who could straighten them out, such as a WG chair or an 2033 Area Director. The default place that press should look for press 2034 contacts for the IETF is . 2036 The fact that those reporters who've gotten it wrong once still come 2037 back to IETF meetings shows that it is possible to get it right 2038 eventually. However, IETF meetings are definitely not for reporters 2039 who are naive about the IETF process (although if you are a reporter 2040 the fact that you are reading this document is a very good sign!). 2041 Furthermore, if you think that you'll get a hot story from attending 2042 an IETF meeting, you are likely to be disappointed. 2044 Considering all this, it's not surprising that some IETFers would 2045 prefer to have the press stay as far away from meetings as possible. 2046 Having a bit of press publicity for protocols that are almost near 2047 completion and will become significant in the industry in the next 2048 year can be a good thing. However, it is the rare reporter who can 2049 resist over-hyping a nascent protocol as the next savior for the 2050 Internet. Such stories do much more harm than good, both for the 2051 readers of the article and for the IETF. 2053 The main reason why a reporter might want to attend an IETF meeting 2054 is not to cover hot technologies (since that can be done in the 2055 comfort of your office by reading the mailing lists) but to meet 2056 people face-to-face. Unfortunately, the most interesting people are 2057 the ones who are also the busiest during the IETF meeting, and some 2058 folks have a tendency to run away when they see a press badge. 2059 However, IETF meetings are excellent places to meet and speak with 2060 document authors and Working Group chairs; this can be quite valuable 2061 for reporters who are covering the progress of protocols. 2063 Reporters who want to find out about "what the IETF is doing" on a 2064 particular topic would be well-advised to talk to more than one 2065 person who is active on that topic in the IETF, and should probably 2066 try to talk to the WG chair in any case. It's impossible to 2067 determine what will happen with a draft by looking at the draft or 2068 talking to the draft's author. Fortunately, all WGs have archives 2069 that a reporter can look through for recent indications about what 2070 the progress of a draft is; unfortunately, few reporters have the 2071 time or inclination to do this kind of research. Because the IETF 2072 doesn't have a press liaison, magazines or newspapers that run a 2073 story with errors won't hear directly from the IETF and therefore 2074 often won't know what they did wrong, so they might easily do it 2075 again later. 2077 9. Security Considerations 2079 Section 6.4.4 explains why each RFC is required to have a Security 2080 Considerations section and gives some idea of what it should and 2081 should not contain. Other than that information, this document does 2082 not touch on Internet security. 2084 10. Acknowledgements 2086 The previous version of this document, RFC 4677, was co-authored with 2087 Susan Harris, who put an incredible amount work and feeling into the 2088 final product. Other contributors include Brian Carpenter, Scott 2089 Bradner, Michael Patton, Donald E. Eastlake III, Tony Hansen, Pekka 2090 Savola, Lisa Dusseault, Russ Housley, the IETF Secretariat, members 2091 of the User Services Working Group, and members of the PESCI (Process 2092 Evolution Consideration for the IETF) design team. 2094 The original version of this document, published in 1994, was written 2095 by Gary Malkin. His knowledge of the IETF, insights, and unmatched 2096 writing style set the standard for this later revision, and his 2097 contributions to the current document are also much appreciated. 2099 11. Informative References 2101 [BCP10] Galvin, J., "IAB and IESG Selection, Confirmation, and 2102 Recall Process: Operation of the Nominating and Recall 2103 Committees", BCP 10, RFC 3777, June 2004. 2105 [BCP101] Austein, R. and B. Wijnen, "Structure of the IETF 2106 Administrative Support Activity (IASA)", BCP 101, 2107 RFC 4071, April 2005. 2109 [BCP102] Daigle, L. and Internet Architecture Board, "IAB Processes 2110 for Management of IETF Liaison Relationships", BCP 102, 2111 RFC 4052, April 2005. 2113 [BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 2114 Handling Liaison Statements to and from the IETF", 2115 BCP 103, RFC 4053, April 2005. 2117 [BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in 2118 the IETF Standards Process", BCP 11, RFC 2028, 2119 October 1996. 2121 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 2122 Requirement Levels", BCP 14, RFC 2119, March 1997. 2124 [BCP22] Scott, G., "Guide for Internet Standards Writers", BCP 22, 2125 RFC 2360, June 1998. 2127 [BCP25] Bradner, S., "IETF Working Group Guidelines and 2128 Procedures", BCP 25, RFC 2418, September 1998. 2130 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2131 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2132 May 2008. 2134 [BCP39] Internet Architecture Board and B. Carpenter, "Charter of 2135 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 2136 May 2000. 2138 [BCP45] Harris, S., "IETF Discussion List Charter", BCP 45, 2139 RFC 3005, November 2000. 2141 [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 2142 Text on Security Considerations", BCP 72, RFC 3552, 2143 July 2003. 2145 [BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78, 2146 RFC 5378, November 2008. 2148 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 2149 Technology", BCP 79, RFC 3979, March 2005. 2151 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 2152 3", BCP 9, RFC 2026, RFC 6410, October 1996. 2154 [BCP95] Alvestrand, H., "A Mission Statement for the IETF", 2155 BCP 95, RFC 3935, October 2004. 2157 [BCP97] Bush, R. and T. Narten, "Clarifying when Standards Track 2158 Documents may Refer Normatively to Documents at a Lower 2159 Level", BCP 97, RFC 3967, December 2004. 2161 [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are 2162 Standards", RFC 1796, April 1995. 2164 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 2165 RFC 2223, October 1997. 2167 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 2168 Understanding Concerning the Technical Work of the 2169 Internet Assigned Numbers Authority", RFC 2860, June 2000. 2171 [RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, 2172 "Document Shepherding from Working Group Last Call to 2173 Publication", RFC 4858, May 2007. 2175 [RFC6635] Kolkman, O. and J. Halpern, "RFC Editor Model (Version 2176 2)", RFC 6635, March 2012. 2178 [STD3] Braden, R., "Requirements for Internet Hosts - Application 2179 and Support", STD 3, RFC 1123, October 1989. 2181 Appendix A. Related Information 2183 A.1. Why "the Tao"? 2185 Pronounced "dow", Tao is the basic principle behind the teachings of 2186 Lao-tse, a Chinese master. Its familiar symbol is the black-and- 2187 white yin-yang circle. Taoism conceives the universe as a single 2188 organism, and human beings as interdependent parts of a cosmic whole. 2189 Tao is sometimes translated "the way", but according to Taoist 2190 philosophy the true meaning of the word cannot be expressed in words. 2192 A.2. Useful Email Addresses 2194 Some useful email addresses are listed here. These addresses may 2195 change from time to time, and it's a good idea to check the IETF web 2196 pages for the correct address before sending your mail. 2198 Address Description 2199 ----------------------------------------------------------------- 2200 ietf-action@ietf.org Requests for things to be done when you 2201 don't know exactly where to send the 2202 request 2204 iana@iana.org Internet Assigned Numbers Authority 2206 rfc-editor@rfc-editor.org RFC Editor 2208 Online upload pages are planned for the future to facilitate 2209 submission of Internet-Drafts, Proceedings, and Liaison statements. 2211 A.3. Useful Documents and Files 2213 The IETF web site, http://www.ietf.org, is the best source for 2214 information about meetings, Working Groups, Internet-Drafts, RFCs, 2215 IETF email addresses, and much more. 2217 Check the IESG web pages, http://www.ietf.org/iesg.html, to find up- 2218 to-date information about drafts processed, RFCs published, and 2219 documents in Last Call, as well as the monthly IETF status reports. 2221 A.4. Acronyms and Abbreviations Used in the Tao 2223 Some of the acronyms and abbreviations from this document are listed 2224 below. 2226 Term Meaning 2227 ----------------------------------------------------------------- 2228 AD Area Director 2229 BCP Best Current Practice 2230 BOF Birds of a Feather 2231 FAQ Frequently Asked Question(s) 2232 FYI For Your Information (RFC) 2233 IAB Internet Architecture Board 2234 IAD IETF Administrative Director 2235 IANA Internet Assigned Numbers Authority 2236 IAOC IETF Administrative Oversight Committee 2237 IASA IETF Administrative Support Activity 2238 ICANN Internet Corporation for Assigned Names and Numbers 2239 I-D Internet-Draft 2240 IESG Internet Engineering Steering Group 2241 IETF Internet Engineering Task Force 2242 IPR Intellectual property rights 2243 IRTF Internet Research Task Force 2244 ISOC Internet Society 2245 RFC Request for Comments 2246 STD Standard (RFC) 2247 WG Working Group 2249 Appendix B. IETF Guiding Principles 2251 If you've gotten this far in the Tao, you've learned a lot about how 2252 the IETF works. What you'll find in this appendix summarizes much of 2253 what you've read and adds a few new points to ponder. Be sure to 2254 read through all the principles; taken as a whole, they'll give you a 2255 new slant on what makes the IETF work. 2257 B.1. General 2259 P1. The IETF works by an open process and by rough consensus. This 2260 applies to all aspects of the operation of the IETF, including 2261 creation of IETF documents and decisions on the processes that 2262 are used. But the IETF also observes experiments and running 2263 code with interest, and this should also apply to the 2264 operational processes of the organization. 2266 P2. The IETF works in areas where it has, or can find, technical 2267 competence. 2269 P3. The IETF depends on a volunteer core of active participants. 2271 P4. Participation in the IETF or of its WGs is not fee-based or 2272 organizationally defined, but is based upon self-identification 2273 and active participation by individuals. 2275 B.2. Management and Leadership 2277 P5. The IETF recognizes leadership positions and grants power of 2278 decision to the leaders, but decisions are subject to appeal. 2280 P6. Delegation of power and responsibility are essential to the 2281 effective working of the IETF. As many individuals as possible 2282 will be encouraged to take on leadership of IETF tasks. 2284 P7. Dissent, complaint, and appeal are a consequence of the IETF's 2285 nature and should be regarded as normal events, but ultimately 2286 it is a fact of life that certain decisions cannot be 2287 effectively appealed. 2289 P8. Leadership positions are for fixed terms (although we have no 2290 formal limitation on the number of terms that may be served). 2292 P9. It is important to develop future leaders within the active 2293 community. 2295 P10. A community process is used to select the leadership. 2297 P11. Leaders are empowered to make the judgment that rough consensus 2298 has been demonstrated. Without formal membership, there are no 2299 formal rules for consensus. 2301 B.3. Process 2303 P12. Although the IETF needs clear and publicly documented process 2304 rules for the normal cases, there should be enough flexibility 2305 to allow unusual cases to be handled according to common sense. 2306 We apply personal judgment and only codify when we're certain. 2307 (But we do codify who can make personal judgments.) 2309 P13. Technical development work should be carried out by tightly 2310 chartered and focused Working Groups. 2312 P14. Parts of the process that have proved impractical should be 2313 removed or made optional. 2315 B.4. Working Groups 2317 P15. Working Groups (WGs) should be primarily responsible for the 2318 quality of their output; WG chairs as WG leaders, backed up by 2319 the IETF leadership, should act as a quality backstop. 2321 P16. WGs should be primarily responsible for assessing the negative 2322 impact of their work on the Internet as a whole, and therefore 2323 for obtaining cross-area review; the IETF leadership should act 2324 as a cross-area backstop. 2326 P17. Early review of documents, particularly by WGs, is more 2327 effective in dealing with major problems than late review. 2329 P18. Area Directors (ADs) are responsible for guiding the formation 2330 and chartering of WGs, for giving them direction as necessary, 2331 and for terminating them. WG chairs serve at the pleasure of 2332 the responsible AD. 2334 P19. WG chairs are responsible for ensuring that WGs execute their 2335 charters, meet their milestones, and produce deliverables that 2336 are ready for publication. Document editors serve at the 2337 pleasure of the WG chair. 2339 P20. ADs are responsible for arranging backstop review and final 2340 document approval. 2342 B.5. Documents 2344 P21. IETF standards often start as personal drafts, may become WG 2345 drafts, and are approved for permanent publication by a 2346 leadership body independent of the WG or individuals that 2347 produced them. 2349 P22. IETF standards belong to the community, not to their authors. 2350 But authorship is recognized and valued, as are lesser 2351 contributions than full authorship. 2353 P23. Technical quality and correctness are the primary criteria for 2354 reaching consensus about documents. 2356 P24. IETF specifications may be published as Informational, 2357 Experimental, Standards Track, Historic, or Best Current 2358 Practice. 2360 P25. IETF Standards Track specifications are not considered to be 2361 satisfactory standards until interoperable independent 2362 implementations have been demonstrated. (This is the 2363 embodiment of the "running code" slogan.) However, the IETF 2364 does not take responsibility for interoperability tests and 2365 does not certify interoperability. 2367 P26. IETF processes are published as Best Current Practice 2368 documents. 2370 P27. Useful information that is neither a specification nor a 2371 process may be published as Informational. 2373 P28. Obsolete or deprecated specifications and processes may be 2374 downgraded to Historic. 2376 P29. The standards track should distinguish specifications that have 2377 been demonstrated to interoperate. 2379 P30. Standards Track and Best Current Practice documents must be 2380 subject to IETF wide rough consensus (Last Call process). WG 2381 rough consensus is normally sufficient for other documents. 2383 P31. Substantive changes made as a result of IETF Last Call or IESG 2384 evaluation must be referred back to the WG. 2386 P32. The IETF determines requirements for publication and archiving 2387 of its documents. 2389 Author's Address 2391 Paul Hoffman 2392 VPN Consortium 2393 127 Segre Place 2394 Santa Cruz, CA 95060 2395 US 2397 EMail: paul.hoffman@vpnc.org