idnits 2.17.1 draft-moonesamy-ietf-newcomers-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2012) is 4331 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3005 (Obsoleted by RFC 9245) -- Obsolete informational reference (is this intentional?): RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 4879 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6220 (Obsoleted by RFC 8722) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Moonesamy 3 Internet-Draft 4 Intended Status: Informational 5 Expires: December 11, 2012 June 9, 2012 7 The Internet Engineering Task Force: A guide for newcomers 8 draft-moonesamy-ietf-newcomers-00 10 Abstract 12 This document describes the inner workings of Internet Engineering 13 Task Force (IETF). It is an informal guide for newcomers to the 14 IETF. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials,this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. About this document . . . . . . . . . . . . . . . . . . . . 4 68 2. What Is the IETF . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Note Well . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Internet Architecture Board (IAB) . . . . . . . . . . . . . 5 72 3.2. Internet Engineering Steering Group (IESG) . . . . . . . . 5 73 3.2.1. Working Groups . . . . . . . . . . . . . . . . . . . . 6 74 3.4 Internet Research Task Force (IRTF) . . . . . . . . . . . . 7 75 4. Participating in the IETF . . . . . . . . . . . . . . . . . . . 7 76 4.1. IETF Mailing Lists . . . . . . . . . . . . . . . . . . . . 8 77 5. IETF Meetings . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.2. Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.3. Planning your week . . . . . . . . . . . . . . . . . . . . 10 81 5.3.1. Dress Code . . . . . . . . . . . . . . . . . . . . . . 11 82 5.3.2. Social Event . . . . . . . . . . . . . . . . . . . . . 11 83 5.3.3. Working Group Sessions . . . . . . . . . . . . . . . . 11 84 5.3.4. Birds of a Feather (BOF) . . . . . . . . . . . . . . . 12 85 5.4. Proceedings . . . . . . . . . . . . . . . . . . . . . . . . 13 86 6. Where Do I Fit In . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.1. Newcomers . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 6.2. IT Managers . . . . . . . . . . . . . . . . . . . . . . . . 14 89 6.3. Network Operators and ISPs . . . . . . . . . . . . . . . . 14 90 6.4. Networking Hardware and Software Vendors . . . . . . . . . 15 91 6.5. Academics . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 6.6. Press Coverage . . . . . . . . . . . . . . . . . . . . . . 15 93 7. Getting an RFC Published . . . . . . . . . . . . . . . . . . . 16 94 7.1. Letting Go Gracefully . . . . . . . . . . . . . . . . . . . 17 95 7.2. Internet-Draft . . . . . . . . . . . . . . . . . . . . . . 18 96 7.2.1 Internet-Draft Names . . . . . . . . . . . . . . . . . . 18 97 7.2.2. Writing an Internet-Draft . . . . . . . . . . . . . . . 19 98 7.2.2.1. Security Considerations . . . . . . . . . . . . . . 20 99 7.2.2.2. IANA Considerations . . . . . . . . . . . . . . . . 20 100 7.2.3. Submitting an Internet-Draft . . . . . . . . . . . . . 20 101 7.2.4. Last Call . . . . . . . . . . . . . . . . . . . . . . . 20 102 7.2.5. IESG Evaluation . . . . . . . . . . . . . . . . . . . . 21 103 8. Administrative Support . . . . . . . . . . . . . . . . . . . . 21 104 8.1. IETF Administrative Support Activity . . . . . . . . . . . 21 105 8.2. IETF Secretariat . . . . . . . . . . . . . . . . . . . . . 21 106 9. Organizational Relationships . . . . . . . . . . . . . . . . . 22 107 9.1. IETF Trust . . . . . . . . . . . . . . . . . . . . . . . . 22 108 9.2. Internet Society . . . . . . . . . . . . . . . . . . . . . 22 109 9.3. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . . 22 110 9.4. Internet Assigned Numbers Authority (IANA) . . . . . . . . 22 111 9.5. Liaisons between the IETF and other Standards 112 Organizations . . . . . . . . . . . . . . . . . . . . . . . 22 113 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 114 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 115 11.1. Informative References . . . . . . . . . . . . . . . . . . 23 116 Appendix A. Acronyms and Abbreviations Used . . . . . . . . . . . 25 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 119 1. Background 121 The first IETF meeting was held in January 1986 at Linkabit in San 122 Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in 123 October 1986, was the first that vendors attended. The concept of 124 Working Groups was introduced at the 5th IETF meeting at the NASA 125 Ames Research Center in California in February 1987. The 7th IETF, 126 held at MITRE in McLean, Virginia, in July 1987, was the first 127 meeting with more than 100 attendees. The 14th IETF meeting was held 128 at Stanford University in July 1989. It marked a major change in the 129 structure of the IETF. 131 The structure of the IAB (then the Internet Activities Board, now the 132 Internet Architecture Board), which until that time oversaw many 133 "task forces", was changed, leaving it with only two: the IETF and 134 the IRTF. The IRTF is tasked to consider long-term research problems 135 in the Internet. The IETF also changed at that time. 137 After the Internet Society (ISOC) was formed in January 1992, the IAB 138 proposed to ISOC that the IAB's activities should take place under 139 the auspices of the Internet Society. During INET92 in Kobe, Japan, 140 the ISOC Trustees approved a new charter for the IAB to reflect the 141 proposed relationship. 143 The IETF met in Amsterdam, The Netherlands, in July 1993. This was 144 the first IETF meeting held in Europe, and the US/non-US attendee 145 split was nearly 50/50. The IETF first met in Asia (in Adelaide, 146 Australia) in 2000. 148 1.1. About this document 150 Attendance at the Internet Engineering Task Force (IETF) meetings has 151 grown phenomenally since the early years. When the meetings were 152 small, it was relatively easy for a newcomer to understand how the 153 IETF works. Nowadays a newcomer meets many more new people, some 154 previously known only as the authors of documents or through email 155 messages. This document describes several aspects of the IETF with 156 the goal of explaining to newcomers how the IETF works. The acronyms 157 and abbreviations used in this document are expanded in place and are 158 explained in Appendix A. The RFCs cited as references provide more 159 details about the IETF. 161 2. What Is the IETF 163 The IETF is not a traditional standards organization although many 164 specifications that are produced become standards [RFC2026][RFC6410]. 165 The IETF is unusual in that it is not registered as an organization 166 or incorporated in any country. It does not have members or a board 167 of directors. The IETF is open to anyone; it does not charge any 168 fees or has any requirements for participation. The closest thing 169 there is to being an IETF member is by participating in the 170 discussions on the IETF mailing lists. 172 The IETF is made up of volunteers, many of whom meet three times a 173 year at IETF meetings. Anyone may register for a meeting and then 174 attend. Many of the attendees are new to the IETF at each meeting. 175 Some of those go on to become regular attendees. 177 The goal of the IETF is to make the Internet work better. The 178 Mission Statement documented in RFC 3935 [RFC3935] describes what the 179 IETF is trying to achieve. The IETF in no way runs the Internet. The 180 IETF makes voluntary standards which are often adopted by Internet 181 users. 183 A summary of the IETF work and events of the last day is available at 184 https://tools.ietf.org/dailydose/ 186 2.1. Note Well 188 The "Note Well" (see http://www.ietf.org/about/note-well.html ) lays 189 out the rules for IETF process and intellectual property rights. You 190 should read it carefully because you are deemed to agree to the "Note 191 Well" by participating in the IETF. 193 3. Hierarchy 195 3.1. Internet Architecture Board (IAB) 197 The IAB [RFC2850] is responsible for keeping an eye on the "big 198 picture" of the Internet. The IAB stays informed about important 199 long-term issues in the Internet. It brings these topics to the 200 attention of people it thinks should know about them. IAB members 201 are selected for two-year positions by the IETF community. 203 The IAB focuses on long-range planning and coordination among the 204 various areas of IETF activity. It pays special attention to 205 emerging activities in the IETF. When a new IETF Working Group is 206 proposed, the IAB reviews its charter for architectural consistency 207 and integrity. Even before the group is chartered, IAB members 208 discuss new ideas with the people proposing them. 210 The IAB sponsors and organizes the Internet Research Task Force and 211 convenes invitational workshops that provide in-depth reviews of 212 specific Internet architectural issues. Typically, the workshop 213 reports make recommendations to the IETF community and to the 214 Internet Engineering Steering Group (IESG). The IAB also approves the 215 nominations of IESG members and acts acts as the appeals board for 216 appeals against IESG. 218 3.2. Internet Engineering Steering Group (IESG) 220 The IESG [RFC3710] is responsible for technical management of IETF 221 activities and the Internet standards process. It administers the 222 process. The IESG doesn't exercise much direct leadership, such as 223 the kind you will find in many other standards organizations. As its 224 name suggests, its role is to set directions rather than to give 225 orders. The IESG gets IETF Working Groups (WGs) started and finished 226 and makes sure that the Internet-Drafts that are about to become IETF 227 RFCs are correct. 229 The IESG consists of the Area Directors (ADs) appointed for two 230 years. The process for choosing the members of the IAB and IESG is 231 detailed in RFC 3777 [RFC3777]. The current Areas and abbreviations 232 are shown below. 234 Area Description 235 ----------------------------------------------------------------- 236 Applications (APP) Protocols seen by user programs such as 237 email and the web 239 General (GEN) IETF process and catch-all for WGs that 240 don't fit in other Areas (which is 241 rare) 243 Internet (INT) Different ways of moving IP packets and 244 DNS information 246 Operations and Operational aspects, network monitoring, 247 Management (OPS) and configuration 249 Real-time Delay-sensitive interpersonal 250 Applications and communications 251 Infrastructure (RAI) 253 Routing (RTG) Getting packets to their destinations 255 Security (SEC) Authentication and privacy 257 Transport (TSV) Special services for special packets 259 The IESG has a great deal of influence on whether Internet-Drafts 260 become RFCs. IETF participants sometimes reverently ask Area 261 Directors for their opinion on a particular subject. When asked for 262 specific technical comments the Area Directors often defer to IETF 263 participants whom they feel have more knowledge than they do on that 264 topic. 266 The entire IESG reviews each Internet-Draft that is proposed to 267 become a RFC to help avoid having IETF protocols which are at odds 268 with each other. For example, the result of one Working Group might 269 clash with a technology developed in a Working Group from another 270 Area. The Area Directors for a particular Area are expected to know 271 more about the combined work of the Working Groups in that Area than 272 anyone else. The IESG usually moves in a reactive fashion because of 273 its high workload. 275 3.2.1. Working Groups 277 The vast majority of the IETF's work is done in many Working Groups 278 [RFC2418]; at the time of this writing, there are about 115 different 279 Working Groups. Each Working Group has one or two chairs. 281 A Working Group is really just a mailing list (see 282 https://datatracker.ietf.org/wg/ ). Anyone can join the Working 283 Group by subscribing to the mailing list. Each Working Group has a 284 charter that the Working Group is supposed to follow. The charter 285 states the scope of discussion for the Working Group, as well as its 286 goals. The Working Group's mailing list and face-to-face meetings 287 are supposed to focus on just what is in the charter and not to 288 wander off on other topics. The large majority of the discussion 289 should be on the topics listed in the charter. Some Working Group 290 charters specify what the Working Group will not do, particularly if 291 there were some attractive but nebulous topics brought up during the 292 drafting of the charter. 294 The IESG usually approves most Working Group requests for Internet- 295 Drafts to be published as RFCs. It may step in when something has 296 gone wrong. The quality of the IETF standards comes both from the 297 review they get in a Working Group and the scrutiny that they gets 298 from the IESG. 300 3.4 Internet Research Task Force (IRTF) 302 The Internet Research Task Force (IRTF) [RFC2014] has responsibility 303 for organizing groups to investigate research topics related to the 304 Internet protocols, applications, and technology. The products of a 305 Research Group are research results that may be disseminated by 306 publication in scholarly journals and conferences, as white papers 307 for the community or as Informational RFCs. 309 4. Participating in the IETF 311 Read - Review the Internet-Drafts in your area of expertise and 312 comment on them in the Working Groups. Participate in the discussion 313 in a friendly and helpful manner with the goal of improving the 314 proposal. Listen much more than you speak. If you disagree, debate 315 the technical issues: never attack the people. 317 Implement - Write programs that use the current Internet standards. 318 The standards aren't worth much unless they are available to Internet 319 users. Implement even the minor standards, since they will become 320 less minor if they appear in more software. Report any problems you 321 find with the standards so that the standard can be clarified in 322 later revisions. One of the oft-quoted tenets of the IETF is 323 "running code wins", so you can help support the standards you want 324 to become more widespread by creating more running code. You can 325 help the development of protocols before they become standards by 326 implementing (but not deploying) from I-Ds to ensure that the authors 327 have done a good job. If you find errors or omissions, offer 328 improvements based on your implementation experience. 330 Write - Edit or co-author Internet-Drafts in your area of expertise. 331 Do this for the benefit of the Internet community, not to get your 332 name (or, even worse, your company's name) on a document. Authors of 333 Internet-Drafts are subject to all kinds of technical and sometimes 334 personal criticism. Receive it with equanimity and use it to improve 335 your draft in order to produce the best and most interoperable 336 standard. 338 4.1. IETF Mailing Lists 340 The IETF announcement mailing list (see 341 https://www.ietf.org/mailman/listinfo/IETF-Announce ) is where all 342 important information, RFC announcements and Last Calls are sent. 343 The is IETF general discussion list (see 344 https://www.ietf.org/mailman/listinfo/ietf ) where IETF participants 345 comment about Internet-Drafts going through Last Call. Non- 346 subscribers may have their postings to an IETF mailing list delayed 347 until the messages are approved by the mailing list moderator. 349 The IETF general discussion list is unmoderated. IETF participants 350 generally post messages to it to express their opinions about issues 351 affecting the IETF or the Internet. The IETF general discussion list 352 is not a place for companies or individuals to solicit or advertise, 353 as noted in the IETF Discussion List Charter [RFC3005]. The list 354 have two "sergeants at arms" who keep an eye open for inappropriate 355 postings. There is a process for banning persistent offenders from 356 the list, but fortunately this is extremely rare. 358 The IETF mailing lists represent the IETF participants at large. It 359 is important to note that attending an IETF meeting does not mean 360 you'll be automatically added to IETF mailing lists. It is worth 361 noting that neither attendee names and addresses nor IETF mailing 362 lists are ever offered for sale. 364 5. IETF Meetings 366 The computer industry is rife with conferences, seminars, 367 expositions, and all manner of other kinds of meetings. IETF face- 368 to-face meetings are nothing like these. The meetings, held three 369 times a year, are week-long gatherings whose primary goal is to 370 reinvigorate the Working Groups to get their tasks done, and whose 371 secondary goal is to promote a fair amount of mixing between the 372 Working Groups and the Areas. The cost of the meetings is paid by 373 the people attending and by the corporate host for each meeting. 374 IETF meetings are of little interest to sales and marketing folks, 375 but of high interest to engineers and developers. 377 The general flow of an IETF meeting is that it begins with tutorials 378 and an informal gathering on Sunday, and that there are WG and BoF 379 sessions from Monday to Friday. A WG session lasts between one to 380 two and a half hours. Some WGs have several sessions during the 381 week. 383 There are two plenary sessions, one technical and one administrative, 384 in the evenings during the week. The technical plenary is organized 385 by the IAB and usually has one or two panels of experts on topics of 386 interest across many WGs and Areas. The administrative plenary, 387 organized by the IETF Chair, covers things like progress reports from 388 the RFC Editor and announcements of upcoming meetings. The plenaries 389 are a good time to share with the IESG and IAOC. Praise is welcome. 390 It is more often a venue for people to raise their concerns or 391 complain about the IETF. 393 The IETF meets in North America, Europe and Asia approximately once a 394 year in each region. The past few meetings have had about 1,200 395 attendees. There have been more than 83 IETF meetings so far, and a 396 list of upcoming meetings is available on the IETF web pages, 397 http://www.ietf.org/meeting/upcoming.html. 399 Newcomers to IETF face-to-face meetings are often in a bit of shock. 400 They expect them to be like other standards bodies or like computer 401 conferences. Fortunately, the shock wears off after a day or two, 402 and many new attendees get quite animated about how much fun they are 403 having. Some IETF participants can be surprisingly rude, such as 404 talking loudly during functions when someone is speaking at the 405 microphone or pushing through a crowd to get to food or drinks. This 406 type of anti-social behavior seems to be more common at IETF meetings 407 than at computer conferences. Newcomers should be patient with the 408 old folks; these folks sometimes provide good advice. 410 One particular feature of IETF meetings is the use of wireless 411 Internet connections throughout the meeting space. It is common to 412 see people in a Working Group meeting apparently reading email or 413 perusing the web during presentations they find boring. Sometimes 414 they may be consulting the drafts under discussion, looking up 415 relevant material online or following another WG meeting using 416 instant messaging. 418 5.1. Registration 420 To attend an IETF meeting, you have to register and pay a 421 registration fee. The meeting site and advance registration are 422 announced about two months ahead of the meeting. An announcement 423 goes out via email to the IETF-announce mailing list, and information 424 is posted on the IETF web site, http://www.ietf.org, that same day. 426 You can register and pay on the web before the meeting or in person 427 at the meeting. To get a lower registration fee, you must pay by the 428 early registration deadline (about one week before the meeting). The 429 registration fee covers all of the week's sessions, the Sunday 430 evening welcome reception (cash bar), daily continental breakfasts, 431 and afternoon beverage and snack breaks. 433 Registration is open throughout the week of the meeting. It is 434 highly recommended that attendees arrive for early registration, 435 usually beginning at noon on Sunday and continuing throughout the 436 Sunday evening reception. The reception is a popular event where you 437 can get a small bite to eat and socialize with other early arrivals. 439 If you need to leave messages for other attendees, you can do so at 440 the cork boards that are often near the registration desk. These 441 cork boards will also have last-minute meeting changes and room 442 changes. You can also turn in lost-and-found items to the 443 registration desk. At the end of the meeting, anything left over 444 from the lost-and-found will usually be turned over to the hotel or 445 brought back to the IETF Secretariat's office. 447 The IETF registration desk is often a convenient place to arrange to 448 meet people. If someone says "meet me at registration", you should 449 clarify if they mean the IETF registration desk, or the hotel 450 registration desk. This has been a common cause of missed 451 connections. 453 5.2. Agenda 455 The agenda for the IETF meetings is a very fluid thing. It is 456 available on the web starting a few weeks before the meeting. Some 457 Working Groups meet multiple times during a meeting. 459 The final agenda is simply the version that went to the printer. A 460 map showing the room locations are also shown on the agenda 461 distributed at the meeting. Room assignments can change as the 462 agenda changes. The Secretariat will post agenda changes on the 463 bulletin board near the IETF registration desk (not the hotel 464 registration desk). 466 5.3. Planning your week 468 IETF Working Group sessions are scheduled from Monday morning through 469 Friday afternoon. It is best to plan to be present the whole week, 470 to benefit from cross-fertilization between Working Groups and from 471 hallway discussions. As noted below, the agenda is fluid, and there 472 have been many instances of participants missing important sessions 473 due to last-minute scheduling changes after their travel plans were 474 fixed. Being present the whole week is the only way to avoid this 475 annoyance. 477 If you cannot find meetings all week to interest you, you can still 478 make the most of the IETF meeting by working between sessions. Most 479 IETF attendees carry laptop computers. It is common to see many in 480 the hallways working during meeting sessions. There is often good 481 wireless Internet coverage in many places of the meeting venue 482 (restaurants, coffee shops, and so on), so catching up on email when 483 not in meetings is a fairly common task for IETFers. 485 5.3.1. Dress Code 487 Many newcomers are often embarrassed when they show up Monday morning 488 in suits, to discover that everybody else is wearing T-shirts, jeans 489 (shorts, if weather permits) and sandals. The general rule is "dress 490 for the weather" (unless you plan to work so hard that you won't go 491 outside, in which case, "dress for comfort" is the rule). 493 People attending an IETF meeting usually wear a name tag. Members of 494 the press wear orange-tinted badges. Some people have a little 495 colored dot on their name tag. A few people have more than one. 496 These dots identify people who have volunteered to do a lot of extra 497 work. The colors have the meanings shown below. 499 Color Meaning 500 -------------------------------------- 501 Blue Working Group/BOF chair 502 Green Host group 503 Red IAB member 504 Yellow IESG member 505 Orange Nominating Committee member 506 Purple IAOC 507 Pink IRSG member 508 Teal RSE 510 Local hosts are the people who can answer questions about restaurants 511 and points of interest in the area. 513 5.3.2. Social Event 515 The social event is sometimes high-tech-related event, or it might be 516 in an art museum or a reception hall. Not all IETF meetings have 517 social events. The social event is designed to give people a chance 518 to meet on a social rather than technical level. Everyone is 519 encouraged to wear their name tags and leave their laptops behind. 521 5.3.3. Working Group Sessions 523 The heart of an IETF meeting is the Working Group sessions. Different 524 WGs chairs have very different styles, so it is impossible to 525 generalize how a WG meeting will feel. Even though nearly all WGs 526 have agendas for their meetings, some meetings stick tightly to their 527 agenda while others are run more loosely. 529 There are a few important things that are true for all WG sessions at 530 an IETF meeting. Near the beginning of the meeting, the chair will 531 pass around the "blue sheets", which are paper forms on which 532 everyone prints their name and puts their email address. These are 533 used for long-term archival purpose to show how many people came to a 534 particular meeting and, in rare cases, exactly who showed up. The 535 normal etiquette is to watch where the blue sheets came from and to 536 pass them along in the same direction. 538 When speaking in a meeting, you should always go to the microphones 539 in the room. For controversial topics, there will be a line at the 540 mic, but do not hesitate to be the first person at the mic if you 541 have a question or a contribution to the discussion. The WG chair or 542 presenter will indicate when you can speak. Although it would be 543 easier to just raise your hand from where you are sitting, the mics 544 perform a very useful task: they let the people listening remotely 545 and in the room hear your question or comment. It is also expected 546 that you will say your name at the mic so that the person taking 547 minutes will know who is speaking. 549 IETF procedures require all decisions to be confirmed "on the list" 550 and you will often hear a Working Group chair say, "Let's take it to 551 the list" to close a discussion. 553 5.3.4. Birds of a Feather (BOF) 555 In order to form a Working Group, you need a charter and someone who 556 is able to be chair. In order to get those things, you need to get 557 people interested so that they can help focus the charter and 558 convince an Area Director that the project is worthwhile. A face-to- 559 face meeting is useful for this. A few WGs get started by an Area 560 Director; most start after a face-to-face BOF because attendees have 561 expressed interest in the topic. 563 A Birds of a Feather (BOF) meeting has to be approved by the Area 564 Director in the relevant Area before it can be scheduled. If you 565 think you really need a new WG, approach an AD informally with your 566 proposal and see what he or she thinks. The next step is to request 567 a meeting slot at the next face-to-face meeting. Of course, you 568 don't need to wait for that meeting to get some work done, such as 569 setting up a mailing list and starting to discuss a charter. 571 BOF sessions have a very different tone than do WG meetings. The 572 purpose of a BOF is to make sure that a good charter with good 573 milestones can be created and that there are enough people willing to 574 do the work needed in order to create standards. Some BOFs have 575 Internet-Drafts already in process, whereas others start from 576 scratch. 578 An advantage of having a draft before the BOF is to help focus the 579 discussion. On the other hand, having a draft might tend to limit 580 what the other folks in the BOF want to do in the charter. It's 581 important to remember that most BOFs are held in order to get support 582 for an eventual Working Group, not to get support for a particular 583 document. 585 Some BOFs don't turn into WGs for a variety of reasons. A common 586 problem is that not enough people can agree on a focus for the work. 587 Another typical reason is that the work wouldn't end up being a 588 standard -- if, for example, the document authors don't really want 589 to relinquish change control to a WG. Only two meetings of a BOF can 590 be scheduled on a particular subject; either a WG has to form or the 591 topic should be dropped. 593 5.4. Proceedings 595 IETF proceedings are compiled two months after each meeting and are 596 available on the web. Be sure to look through a copy - the 597 proceedings are filled with information about IETF that you're not 598 likely to find anywhere else. For example, you'll find snapshots of 599 most WG charters at the time of the meeting, giving you a better 600 understanding of the evolution of any given effort. 602 The proceedings sometimes start with an informative message. Each 603 volume contains the final (hindsight) agenda, an IETF overview, Area 604 and Working Group reports, and slides from the protocol and technical 605 presentations. The Working Group reports and presentations are 606 sometimes incomplete, if the materials haven't been turned in to the 607 Secretariat in time for publication. 609 An attendee list is also included, which contains names and 610 affiliations as provided on the registration form. For information 611 about obtaining copies of the proceedings, see the web listing at 612 http://www.ietf.org/meeting/proceedings.html. 614 6. Where Do I Fit In 616 The IETF is different things to different people. There are many 617 people who have been very active in the IETF who have never attended 618 an IETF meeting. Some people attend an IETF meeting to get a feel 619 for the IETF. The following guidelines (based on stereotypes of 620 people in various industries) might help you decide whether you 621 actually want to come and, if so, what might be the best use of your 622 time at your first meeting. 624 6.1. Newcomers 626 Newcomers are encouraged to attend the Newcomer's Orientation on 627 Sunday afternoon which is designed for first-time attendees. The 628 orientation is intended to provide introductory information about the 629 IETF. The session covers the structure of the IETF and how the IETF 630 works. 632 Later in the afternoon is the Newcomer's Meet and Greet, which is 633 only open to newcomers and WG chairs. This is a great place to try 634 to find people knowledgeable in the areas in which you are 635 interested. Feel free to approach any Working Group chair, not just 636 those in your area, to either learn about their Working Group or to 637 have them help find you someone in yours. 639 Newcomers to the IETF not be afraid to strike up conversations with 640 people who have dots on their name tag. If the IAB and IESG members 641 and Working Group and BOF chairs didn't want to talk to anybody, they 642 wouldn't be wearing the dots in the first place. 644 IETF meetings are usually intense times for Area Directors. Talking 645 to an Area Director during an IETF meeting will often lead to a 646 request to send her or him email about two weeks later. When you 647 start a hallway conversation with an Area Director (or even a Working 648 Group chair, for that matter), it is often good to give them about 30 649 seconds of context for the discussion. 651 6.2. IT Managers 653 An IETF meeting is not the places to go if your intention is to find 654 out what will be hot in the Internet industry next year. You can 655 safely assume that going to Working Group meetings will confuse you 656 more than it will help you understand what is happening, or will be 657 happening, in the industry. 659 As an IT manager you might want to consider sending specific people 660 who are responsible for technologies that are under development in 661 the IETF. As these people read the current Internet-Drafts and the 662 messages on the relevant Working Group lists, they will get a sense 663 of whether or not their presence would be worthwhile for your company 664 or for the Working Groups. 666 6.3. Network Operators and ISPs 668 Running a network is hard enough without having to grapple with new 669 protocols or new versions of the protocols with which you are already 670 dealing. If you work for the type of network that is always using 671 the very latest hardware and software, and you are following the 672 relevant Working Groups, you could certainly find participating in 673 the IETF valuable. A fair amount of IETF work also covers many other 674 parts of operations of ISPs and large enterprises, and the input of 675 network operators is quite valuable to keep this work vibrant and 676 relevant. Many of the best operations documents from the IETF come 677 from real-world operators, not vendors and academics. 679 6.4. Networking Hardware and Software Vendors 681 The image of the IETF being mostly ivory tower academics may have 682 been true in the past, but the jobs of typical attendees are now in 683 industry. In most areas of the IETF, employees of vendors are the 684 ones writing the protocols and leading the Working Groups. If you 685 create Internet hardware or software, and no one from your company 686 has ever attended an IETF meeting, it behooves you to come to a 687 meeting if for no other reason than to tell the others how relevant 688 the meeting was or was not to your business. 690 It isn't likely useful, for everyone from a technical department to 691 go, particularly if they are not all reading the Internet-Drafts and 692 following the Working Group mailing lists. Many companies have just 693 a few designated meeting attendees who are chosen for their ability 694 to do complete and useful trip reports. In addition, many companies 695 have internal coordination efforts and a standards strategy. If a 696 company depends on the Internet for some or all of its business, the 697 strategy should probably cover the IETF. 699 6.5. Academics 701 IETF meetings are often excellent places for computer science folks 702 to find out what is happening in the way of soon-to-be-deployed 703 protocols. Professors and grad students (and sometimes overachieving 704 undergraduates) who are doing research in networking or 705 communications can get a wealth of information by following Working 706 Groups in their specific fields of interest. Wandering into 707 different Working Group meetings can have the same effect as going to 708 symposia and seminars in your department. Academics and Researchers 709 are likely to be interested in IRTF activities (see 710 http://www.irtf.org/ ). 712 6.6. Press Coverage 714 Given that the IETF is one of the best-known bodies that is helping 715 move the Internet forward, it's normal for the computer press (and 716 even the trade press) to want to cover its actions. A small number 717 of magazines have assigned reporters and editors to cover the IETF in 718 depth over a long period of time. The default press contact for the 719 IETF is the IETF Administrative Director (IAD), who can be reached at 720 . 722 The main reason why a reporter might want to attend an IETF meeting 723 is not to cover hot technologies (since that can be done in the 724 comfort of your office by reading the mailing lists) but to meet 725 people face-to-face. Unfortunately, the most interesting people are 726 the ones who are also the busiest during the IETF meeting, and some 727 folks have a tendency to run away when they see a press badge. IETF 728 meetings are excellent places to meet and speak with document authors 729 and Working Group chairs. This can be quite valuable for reporters 730 who are covering the progress of protocols. 732 Press errors can occur by saying that the IETF is considering 733 something when in fact there is only an Internet-Draft. It's 734 impossible to determine what will happen with a draft by looking at 735 the draft or talking to the author of the draft. The press is not 736 fully to blame for the mistake since they are usually alerted to the 737 story by a company trying to get publicity for a protocol that they 738 developed or at least support. Reporters who want to find out about 739 what the IETF is doing on a particular topic would be well-advised to 740 talk to more than one person who is active on that topic in the IETF. 741 They should try to talk to the WG chair or Area Director in any 742 case. 744 Having a bit of press publicity for protocols that are almost near 745 completion and will become significant in the industry in the next 746 year can be a good thing. However, it is rare that a reporter can 747 resist over-hyping a nascent protocol as the next big thing for the 748 Internet. Such stories do much more harm than good, both for the 749 readers of the article and for the IETF. 751 7. Getting an RFC Published 753 One of the most common questions seasoned IETF participants hear from 754 newcomers is, "How do I get an IETF standard published?" A much 755 better question is, "Should I write an IETF standard?" since the 756 answer is not always "yes". If you do decide to try to write a 757 document that becomes an IETF standard, be warned that the overall 758 process may be arduous, even if the individual steps are fairly 759 straightforward. Very few people get through the process unscathed 760 though. 762 One of the first things you must decide is whether you want your 763 document to be considered in a Working Group, of you want it to be 764 considered as an individual (that is, non-WG) submission to the IETF. 765 Even though most IETF standards come from Working Groups, some are 767 individual efforts: there might be no appropriate Working Group, or a 768 potentially-appropriate Working Group might be to busy on other work 769 to consider your idea. 771 Every IETF standard, published as an RFC (Request for Comments), 772 starts out as an Internet-Draft (often called an "I-D" or just 773 "draft"). The basic steps for getting something published as an IETF 774 standard are as follows: 776 1. Submit the document as an Internet-Draft 778 2. Convince IETF participants to review and comments on the 779 draft. 781 3. Edit your draft based on the comments. 783 4. Repeat steps 1 through 3 a few times. 785 5. Ask an Area Director to sponsor the draft (if it's an 786 individual submission). If the draft is an official Working 787 Group product, the WG chair will help you with the publication 788 process. 790 6. If the Area Director accepts to sponsor the draft, he or she 791 will do an initial review, and maybe ask for updates before 792 they move it forward. 794 7. Discuss concerns with the IESG members. Their concerns might 795 be resolved with a simple answer or they might require 796 additions or changes to the document. 798 7.1. Letting Go Gracefully 800 Some people do not understand that is that they must give up change 801 control of the protocol for it to be published as a RFC. That is, as 802 soon as you propose that your protocol become an IETF standard, you 803 must fully relinquish control of the protocol. If there is general 804 agreement, parts of the protocol can be completely changed, whole 805 sections can be ripped out, new things can be added, and the name can 806 be changed. 808 Some authors find it very hard to give up control of their pet 809 protocol. If you are one of those people, don't even think about 810 trying to get your protocol to become an IETF standard. On the other 811 hand, if your goal is the best standard possible with the widest 812 implementation, then you might find the IETF process to your liking. 814 The change control on Internet standards doesn't end when the 815 protocol is put on the standards track. The protocol itself can be 816 changed later for a number of reasons, the most common of which is 817 that implementers discover a problem as they implement the standard. 818 These later changes are also under the control of the IETF, not the 819 editors of the standards document. 821 IETF standards exist so that people will use them to write Internet 822 programs that interoperate. They don't exist to document the ideas 823 of their authors, nor do they exist so that a company can say, "We 824 have an IETF standard". If a RFC only has one implementation 825 (whereas two are required for it to advance on the standards track), 826 it was probably a mistake to publish it in the first place. 828 7.2. Internet-Draft 830 Internet-Drafts are tentative documents. They are meant for readers 831 to comment on. The author decides which comments to incorporate in 832 the draft. Internet-Drafts automatically expire from the six months. 833 A person who doesn't understand RFCs (or is intentionally trying to 834 fool people) may brag about having published an Internet-Draft; it 835 takes no significant effort. 837 When you submit an Internet-Draft, you give some publication rights 838 to the IETF. This is so that your Internet-Draft is freely available 839 to everyone who wants to read and comment on it. The rights you do 840 and don't give to the IETF are described in BCP 78 [RFC5378], "IETF 841 Rights in Contributions". Note that authors cannot take someone 842 else's document and pass it off as their own; see BCP 78, section 843 5.6, point (a). 845 7.2.1 Internet-Draft Names 847 There are some informal rules for Internet-Draft naming that have 848 evolved over the years. The author's name is used as part of the 849 filename. Internet-Drafts that revise existing RFCs often have draft 850 names with "bis" in them, meaning "again" or "twice"; for example, a 851 draft might be called "draft-author-rfc2345bis-00.txt". 853 If an Internet-Draft is an official Working Group product, the name 854 will start with "draft-ietf-" followed by the designation of the WG, 855 followed by a descriptive word or two, followed by "00.txt". For 856 example, a draft in the GROW WG about BGP might be named "draft-ietf- 857 grow-bgp-00.txt". If it is not the product of a Working Group, the 858 name will start with "draft-" and the last name of one of the authors 859 followed by a descriptive word or two, followed by "00.txt". After 860 the first revision of a draft, the number in the filename is 861 incremented; for instance, the second edition of the GROW draft named 862 above would be "draft-smith-grow-bgp-01.txt". 864 The filename changes after one or more versions, such as when a 865 personal effort is adopted as a Working Group draft; when a draft has 866 its filename changed, the number reverts to -00. The WG chairs will 867 let the Internet-Drafts administrator know the previous name of the 868 draft when such a name change occurs so that the databases can be 869 kept accurate. 871 7.2.2. Writing an Internet-Draft 873 It is important that multiple readers and implementers of a standard 874 have the same understanding of a document. To this end, information 875 should be orderly and detailed. The reader is more likely to have 876 general networking knowledge and experience rather than expertise in 877 a particular protocol. An explanation of the protocol and its use 878 will give the reader a reference point for understanding the protocol 879 and where it fits in the Internet. The "Guide for Internet Standards 880 Writers" [RFC2360] provides tips that will help you write a standard 881 that leads to interoperability. For instance, it explains how to 882 choose the right number of protocol options, how to respond to out- 883 of-spec behavior, and how to show state diagrams. 885 An Internet-Draft does not need to look exactly like an RFC. If you 886 follow the I-D guidelines given at http://www.ietf.org/ietf/1id- 887 guidelines.txt, chances are quite good that your draft will be fine. 889 One way to make it more likely that developers will create 890 interoperable implementations of standards is to be clear about 891 what's being mandated in a specification. Early RFCs used all kinds 892 of expressions to explain what was needed, so implementors didn't 893 always know which parts were suggestions and which were requirements. 894 As a result, standards writers in the IETF generally agreed to limit 895 their wording to a few specific words with a few specific meanings. 896 The "Key words for use in RFCs to Indicate Requirement Levels" are 897 defined in RFC 2119 [RFC2119]. 899 An Internet-Draft may contain two types of references; normative and 900 informative. A normative reference is a reference to a document that 901 must be followed in order to implement the standard. A informative 902 reference is one that is helpful to an implementer but is not needed. 903 An IETF standard may make a normative reference to any other 904 standards-track RFC that is at the same standards level or higher, or 905 to any "open standard" that has been developed outside the IETF. 907 If you are writing an Internet-Draft and you know of a patent that 908 applies to the technology you're writing about, don't list the patent 909 in the document. Read the IETF IPR page at http://www.ietf.org/ipr 910 and BCP 79 [RFC3979][RFC4879] and file an IPR disclosure. 911 Intellectual property rights aren't mentioned in RFCs because RFCs 912 never change after they are published but knowledge of IPR can change 913 at any time. 915 There is a tool called "xml2rfc" available from 916 http://xml.resource.org. It takes XML-formatted text and generates 917 an Internet-Draft. 919 7.2.2.1. Security Considerations 921 Every RFC requires a "Security Considerations" section. This section 922 should describe any known vulnerabilities of the protocol, possible 923 threats and mechanisms or strategies to address them. Don't gloss 924 over this section -- in particular, don't say, "Here's our protocol, 925 if you want security, just use IPsec". This won't do at all because 926 it doesn't answer the question of how IPsec interacts with your 927 protocol, and vice versa. See "Guidelines for Writing RFC Text on 928 Security Considerations" [RFC3552] for more information on writing 929 good security considerations sections. 931 7.2.2.2. IANA Considerations 933 Many IETF protocols make use of values which are uniquely assigned to 934 ensure consistent interpretation between independent implementations. 935 These assignments are defined in the IETF Protocol Parameter 936 Registries [RFC6220]. For historical reasons these registries are 937 operated by IANA. If you are writing an Internet standard which 938 needs an assignment, read the RFC ( https://www.iana.org/protocols/ ) 939 which defines the registration requirements. Registration is 940 generally done in the "IANA Considerations" [RFC5226] section of an 941 Internet-Draft. 943 7.2.3. Submitting an Internet-Draft 945 Internet-Drafts can be submitted at 946 https://datatracker.ietf.org/submit/ The IETF Tools web pages ( 947 http://tools.ietf.org/ ) has pointers to tools that will automate 948 some of your work for the IETF. There is a very useful checking tool 949 at http://tools.ietf.org/tools/idnits which can be used to help 950 prevent the draft from being rejected due to errors in form and 951 formatting. There is a list of common issues ( 952 http://www.ietf.org/ID-Checklist.html ) that have been known to stop 953 documents in the IESG. 955 7.2.4. Last Call 957 The purpose of IETF Last Call is to get community-wide discussion on 958 an Internet-Draft so the IESG determine whether it has IETF 959 consensus. It is also a time when people in the Working Group who 960 feel that they weren't heard can make their comments to everyone. 961 The IETF Last Call is at least two weeks for Working Group drafts and 962 four weeks for individual submissions. The discussion for a Last 963 Call is held on the IETF general discussion list 964 and is open to everyone. IETF Last Call 965 comments posted by people who have just read the draft for the first 966 time can expose issues that IETF and Working Group regulars may have 967 completely missed. 969 It is generally considered bad form to send IETF Last Call comments 970 on documents that you have not read, or to send comments but not be 971 prepared to discuss your views. The IETF Last Call is not a vote. 972 Campaigns aimed at getting people to post messages in support or 973 opposition to a document usually backfire. 975 7.2.5. IESG Evaluation 977 Any Area Director may record a "DISCUSS" ballot position against an 978 Internet-Draft if he or she has serious concerns. If these concerns 979 cannot be resolved by discussion, an override procedure is defined 980 such that at least two IESG members must express concerns. This 981 procedure helps to ensure that an Area Director's "pet peeve" cannot 982 indefinitely block something. If the IESG approves the draft they 983 ask the RFC Editor to publish it as a RFC. 985 8. Administrative Support 987 8.1. IETF Administrative Support Activity 989 The IETF Administrative Support Activity (IASA) [RFC4071] provides 990 the administrative structure required to support the IETF standards 991 process and to support the IETF's technical activities. Within this 992 activity is the office of the IETF Administrative Director (IAD) and 993 the IETF Administrative Oversight Committee (IAOC). 995 8.2. IETF Secretariat 997 A few people, who are part of the IETF Secretariat, are paid to 998 provide day-to-day logistical support for the IETF, coordinate IETF 999 meetings. The IETF Secretariat is also responsible for keeping the 1000 official Internet-Drafts directory up to date and orderly, 1001 maintaining the IETF web site, and for helping the IESG do its work. 1002 It provides various tools for use by the community and the IESG. The 1003 IETF Secretariat is under contract to IASA, which in turn is 1004 financially supported by the fees collected for attending the IETF 1005 meetings. 1007 There is a list of e-mail addresses to contact ( 1008 https://www.ietf.org/contact-the-ietf.html ) the IETF Secretariat. 1010 9. Organizational Relationships 1012 9.1. IETF Trust 1014 The IETF Trust was set up in 2005 to have a stable and legally- 1015 identifiable entity for the IETF. The IETF Trust holds and licenses 1016 the intellectual property of the IETF. The members of the IETF 1017 Administrative Oversight Committee serve as IETF Trustees. You can 1018 find out more about the IETF Trust at their web site ( 1019 http://trustee.ietf.org ). 1021 9.2. Internet Society 1023 The Internet Society (ISOC) provides insurance coverage for many of 1024 the people holding leadership positions in the IETF process and acts 1025 as a public relations channel for the times that one of the "I" 1026 groups wants to say something to the press. Since 2005 the Internet 1027 Society employs the IETF Administrative Director (IAD) who works 1028 full-time overseeing IETF meeting planning and operational aspects of 1029 the IETF Secretariat. 1031 9.3. RFC Editor 1033 The RFC Editor [RFC4844] edits, formats, and publishes Internet- 1034 Drafts as RFCs, working in conjunction with the IESG. An important 1035 secondary role is to provide one definitive repository for all RFCs 1036 (see http://www.rfc-editor.org ). Once an RFC is published, it is 1037 never revised. If the specification it describes changes, the 1038 standard will be re-published in another RFC that "obsoletes" the 1039 first. 1041 Up through the end of 2009 the RFC Editor was a single entity. The 1042 function was split by the IAB into several roles that can be 1043 performed by different people or organizations. 1045 9.4. Internet Assigned Numbers Authority (IANA) 1047 The Internet Assigned Numbers Authority (IANA) activities are 1048 currently performed by the Internet Corporation for Assigned Names 1049 and Numbers (ICANN). IANA services to the IETF are provided for free 1050 as specified in [RFC2860]. The IETF is not involved in domain name 1051 and IP address assignment functions. 1053 9.5. Liaisons between the IETF and other Standards Organizations 1054 The IETF tries to have cordial relationships with other standards 1055 organizations. The IETF has liaisons ( http://www.ietf.org/liaison ) 1056 with large standards organizations, including the ITU-T (the 1057 Telecommunication Standardization Sector of the International 1058 Telecommunication Union), the W3C (World Wide Web Consortium), the 1059 IEEE (the Institute of Electrical and Electronics Engineers) and the 1060 Unicode Consortium. Liaisons are kept as informal as possible and 1061 must be of demonstrable value in improving the quality of IETF 1062 specifications [RFC2850]. In practice, the IETF prefers liaisons to 1063 take place directly at Working Group level with formal relationships 1064 and liaison documents [RFC4053] in a backup role. 1066 10. Acknowledgments 1068 This document contains a large amount of text from RFC 4677 which is 1069 is known as the Tao of the IETF. 1071 RFC 4677 was co-authored by Paul Hoffman and Susan Harris. 1072 Contributors include Brian Carpenter, Scott Bradner, Michael Patton, 1073 Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault, 1074 Russ Housley, the IETF Secretariat, members of the User Services 1075 Working Group, and members of the PESCI (Process Evolution 1076 Consideration for the IETF) design team. 1078 The original version of RFC 4677, published in 1994, was written by 1079 Gary Malkin. His knowledge of the IETF, insights, and unmatched 1080 writing style set the standard for this later revision, and his 1081 contributions to the RFC 4677 are also much appreciated. 1083 11. References 1085 11.1. Informative References 1087 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 1088 and Procedures", BCP 8, RFC 2014, October 1996. 1090 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1091 3", BCP 9, RFC 2026, October 1996. 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, March 1997. 1096 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 1097 RFC 2360, June 1998. 1099 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1100 Procedures", BCP 25, RFC 2418, September 1998. 1102 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 1103 "Charter of the Internet Architecture Board (IAB)", 1104 BCP 39, RFC 2850, May 2000. 1106 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 1107 Understanding Concerning the Technical Work of the 1108 Internet Assigned Numbers Authority", RFC 2860, June 2000. 1110 [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, 1111 RFC 3005, November 2000. 1113 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1114 Text on Security Considerations", BCP 72, RFC 3552, July 1115 2003. 1117 [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February 1118 2004. 1120 [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 1121 and Recall Process: Operation of the Nominating and Recall 1122 Committees", BCP 10, RFC 3777, June 2004. 1124 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 1125 BCP 95, RFC 3935, October 2004. 1127 [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF 1128 Technology", BCP 79, RFC 3979, March 2005. 1130 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 1131 Handling Liaison Statements to and from the IETF", 1132 BCP 103, RFC 4053, April 2005. 1134 [RFC4071] Austein, R., Ed., and B. Wijnen, Ed., "Structure of the 1135 IETF Administrative Support Activity (IASA)", BCP 101, 1136 RFC 4071, April 2005. 1138 [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC 1139 Series and RFC Editor", RFC 4844, July 2007. 1141 [RFC4879] Narten, T., "Clarification of the Third Party Disclosure 1142 Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. 1144 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1145 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1146 May 2008. 1148 [RFC5378] Bradner, S., Ed., and J. Contreras, Ed., "Rights 1149 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 1150 November 2008. 1152 [RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., 1153 Huston, G., Ed., and Internet Architecture Board, 1154 "Defining the Role and Function of IETF Protocol Parameter 1155 Registry Operators", RFC 6220, April 2011. 1157 [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the 1158 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 1159 October 2011. 1161 Appendix A. Acronyms and Abbreviations Used 1163 Some of the acronyms and abbreviations from this document are listed 1164 below. 1166 Term Meaning 1167 ----------------------------------------------------------------- 1168 AD Area Director 1169 BCP Best Current Practice 1170 BOF Birds of a Feather 1171 IAB Internet Architecture Board 1172 IAD IETF Administrative Director 1173 IANA Internet Assigned Numbers Authority 1174 IAOC IETF Administrative Oversight Committee 1175 IASA IETF Administrative Support Activity 1176 ICANN Internet Corporation for Assigned Names and Numbers 1177 I-D Internet-Draft 1178 IESG Internet Engineering Steering Group 1179 IETF Internet Engineering Task Force 1180 IPR Intellectual property rights 1181 IRTF Internet Research Task Force 1182 ISOC Internet Society 1183 PS Proposed Standard (RFC) 1184 RFC Request for Comments 1185 STD Standard (RFC) 1186 WG Working Group 1188 Authors' Addresses 1190 S. Moonesamy 1191 76, Ylang Ylang Avenue 1192 Quatre Bornes 1193 Mauritius 1195 EMail: sm+ietf@elandsys.com