idnits 2.17.1 draft-malkin-newcomers-guide-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 418: '... later. Payment MUST be accompanied b...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 1992) is 11539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ROSE' on line 314 looks like a reference -- Missing reference section? 'RFC1111' on line 602 looks like a reference -- Missing reference section? 'RFC1150' on line 603 looks like a reference -- Missing reference section? 'RFC1311' on line 604 looks like a reference -- Missing reference section? 'GAID' on line 605 looks like a reference -- Missing reference section? 'RFC1160' on line 606 looks like a reference -- Missing reference section? 'RFC1310' on line 607 looks like a reference -- Missing reference section? 'STD1' on line 608 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft G. Malkin / Xylogics 3 September 1992 5 The Tao of IETF 6 A Guide for New Attendees of the Internet Engineering Task Force 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts). 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 Please check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any other 23 Internet Draft. 25 It is intended that this document will be submitted for consideration 26 as an FYI document. Distribution of this document is unlimited. 28 Abstract 30 Over the last two years, the attendance at Internet Engineering Task 31 Force (IETF) Plenary meetings has grown phenomenally. Approximately 32 38% of the attendees are new to the IETF at each meeting. About 33% 33 of those go on to become regular attendees. When the meetings were 34 smaller, it wasn't very difficult for a newcomer to get to know 35 people and get into the swing of things. Today, however, a newcomer 36 meets many more new people, some previously known only as the authors 37 of Request For Comments (RFC) documents or thought provoking email 38 messages. 40 The purpose of this For Your Information (FYI) RFC is to explain to 41 the newcomers how the IETF works. This will give them a warm, fuzzy 42 feeling and enable them to make the meeting more productive for 43 everyone. This FYI will also provide the mundane bits of information 44 which everyone who attends an IETF meeting should know. 46 Acknowledgments 48 The IETF Secretariat is made up of the following people: Steve Coya 49 (Executive Director of the IETF), Cynthia Clark, Megan Davies, Debra 50 Legare, and Greg Vaudreuil. These are the people behind the 51 Registration Table, and the success, of the IETF meetings. I thank 52 them for their hard work, and for their input and review of this 53 document. Thanks also to Vinton Cerf, Phillip Gross, and Craig 54 Partridge for their review and comments. And, as always, special 55 thanks to April Marine and Skippy. 57 I would also like to thank the management of Xylogics for their 58 strong, continuing support of my IETF activities. 60 63 Table of Contents 65 Section 1 - The "Fun" Stuff 66 What it the IETF? . . . . . . . . . . . . . . . . . . . . . . 2 67 Humble Beginnings . . . . . . . . . . . . . . . . . . . . . . 3 68 The Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 3 69 IETF Mailing Lists . . . . . . . . . . . . . . . . . . . . . 4 70 Registration . . . . . . . . . . . . . . . . . . . . . . . . 5 71 Dress Code . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 Seeing Spots Before Your Eyes . . . . . . . . . . . . . . . . 6 73 Terminal Room . . . . . . . . . . . . . . . . . . . . . . . . 7 74 Social Event . . . . . . . . . . . . . . . . . . . . . . . . 7 75 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 Other General Things . . . . . . . . . . . . . . . . . . . . 8 78 Section 2 - The "You've got to know it" Stuff 79 Registration Bullets . . . . . . . . . . . . . . . . . . . . 9 80 Mailing Lists and Archives . . . . . . . . . . . . . . . . . 10 81 Important Email Addresses . . . . . . . . . . . . . . . . . . 10 82 IETF Proceedings . . . . . . . . . . . . . . . . . . . . . . 11 83 Be Prepared . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 RFCs and Internet-Drafts . . . . . . . . . . . . . . . . . . 12 85 Frequently Asked Questions (and Their Answers) . . . . . . . 13 86 Pointers to Useful Documents and Files . . . . . . . . . . . 14 88 Section 3 - The "Reference" Stuff 89 IETF Area Abbreviations . . . . . . . . . . . . . . . . . . . 17 90 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 95 What is the IETF? 97 The IETF is the protocol engineering, development, and 98 standardization arm of the Internet Architecture Board (IAB). Its 99 mission includes: 101 o Identifying, and proposing solutions to, pressing operational and 102 technical problems in the Internet; 104 o Specifying the development or usage of protocols and the near-term 105 architecture to solve such technical problems for the Internet; 107 o Making recommendations to the IAB regarding standardization of 108 protocols and protocol usage in the Internet; 110 o Facilitating technology transfer from the IRTF to the wider 111 Internet community; and 113 o Providing a forum for the exchange of information within the 114 Internet community between vendors, users, researchers, agency 115 contractors, and network managers. 117 The IETF Plenary meeting is NOT a conference, although there are 118 technical presentations. The IETF is NOT a Standards Organization, 119 although many standards are produced. The IETF IS a group of 120 volunteers who meet three times a year to fulfill the IETF's mission. 122 There is no membership in the IETF. Anyone may register for, and 123 attend, any meeting. The closest thing there is to being an IETF 124 member is being on the IETF mailing lists (see the IETF Mailing Lists 125 section). This is where the best information about current IETF 126 activities and focus can be found. 128 Humble Beginnings 130 The first IETF meeting was held in January, 1986 at Linkabit in San 131 Diego with 15 attendees. The 4th IETF, held at SRI in Menlo Park in 132 October, 1986, was the first at which non-government vendors 133 attended. The concept of Working Groups (WG) was introduced at the 134 5th IETF meeting at the NASA Ames Research Center in California in 135 February, 1987. The 7th IETF, held at MITRE in McLean, Virginia in 136 July, 1987, was the first meeting with over 100 attendees. 138 The 14th IETF meeting was held at Stanford University in July, 1989. 139 It marked a major change in the structure of the IETF universe. The 140 IAB (then, Internet Activities Board), which until that time oversaw 141 many Task Forces, changed its structure to leave only two: the IETF 142 and the Internet Research Task Force (IRTF). The IRTF is tasked to 143 consider the long-term research problems in the Internet. The IETF 144 also changed. Those changes are visible in today's hierarchy. 146 The Hierarchy 148 To completely understand the structure of the IETF, it is useful to 149 understand the overall structure in which the IETF resides. The new 150 Internet Society (ISOC), formed in January 1992, provides the 151 official parent organization for the IETF. The ISOC Board of 152 Trustees appoints the members of the IAB. The IETF and IRTF Chairs 153 are also IAB members. The IAB provides the final technical review of 154 Internet standards. They also provide leadership in the IETF, by 155 virtue of their skills and years of experience. 157 The IETF is divided into nine functional Areas. They are: 158 Applications, Internet Services, Network Management, Operational 159 Requirements, OSI Integration, Routing, Security, Transport and 160 Services, and User Services. Each Area has at least one Area 161 Director. There is also an Area Director who oversees Standards 162 Management. The Area Directors, along with the IETF Chair, form the 163 Internet Engineering Steering Group (IESG). Phillip Gross has been 164 the IETF Chair since the IETF's 7th meeting. He founded the IESG and 165 serves as its Chair as well. The IESG provides the first technical 166 review of Internet standards. They are also responsible for the 167 day-to-day "management" of the IETF. 169 Each Area has several Working Groups. A Working Group is a group of 170 people who work under a charter to achieve a certain goal. That goal 171 may be the creation of an informational document, the creation of a 172 protocol standard, or the resolution of problems in the Internet. 173 Most Working Groups have a finite lifetime. That is, once a Working 174 Group has achieved its goal, it disbands. As in the IETF, there is 175 no official membership for a Working Group. Unofficially, a Working 176 Group member is somebody who's on that Working Group's mailing list. 177 Anyone may attend a Working Group meeting (see the Be Prepared 178 section below). 180 Areas may also have Birds of a Feather (BOF) groups. They generally 181 have the same goals as Working Groups, except that they have no 182 charter and usually only meet once or twice. BOFs are often held to 183 determine if there is enough interest to form a Working Group. 185 IETF Mailing Lists 187 Anyone who plans to attend an IETF meeting should join the IETF 188 announcements mailing list. This is where all of the meeting 189 information, new Internet-Draft and RFC announcements, IESG 190 Recomendations, and Last Calls are posted. People who'd like to "get 191 technical" may also join the IETF discussion list, 192 "ietf@nri.reston.va.us". This was the only list before the 193 announcement list was created and is where discussions of cosmic 194 significance are held (most Working Groups have their own mailing 195 lists for discussions relating to their work). To join the IETF 196 announcement list, send a request to: 198 ietf-announce-request@nri.reston.va.us 200 To join the IETF discussion list, send a request to: 202 ietf-request@nri.reston.va.us 204 To join both of the lists, simply send a single message, to either 205 "-request" address, and indicate that you'd like to join both mailing 206 lists. 208 Do not, ever, under any circumstances, for any reason, send a request 209 to join a list to the list itself! The thousands of people on the 210 list don't need, or want, to know when a new person joins. 211 Similarly, when changing email addresses or leaving a list, send your 212 request only to the "-request" address, not to the main list. This 213 means you!! 215 The IETF discussion list is unmoderated. This means that anyone can 216 express their opinions about issues affecting the Internet. However, 217 it is not a place for companies or individuals to solicit or 218 advertise. Only the Secretariat can send a message to the 219 announcement list. 221 Even though the IETF mailing lists "represent" the IETF membership at 222 large, it is important to note that attending an IETF meeting does 223 not automatically include addition to either mailing list. 225 Registration 227 As previously mentioned, all meeting announcements are sent to the 228 IETF announcement list. Within the IETF meeting announcement is a 229 Registration Form and complete instructions for registering, 230 including, of course, the cost. The Secretariat highly recommendeds 231 that attendees preregister. Early registration, which ends about one 232 month before the meeting, carries a lower registration fee. As the 233 size of the meetings has grown, so has the length of the lines at the 234 registration desk. Fortunately, there are three lines: the 235 "preregistered and prepaid" line (which moves very quickly); the 236 "preregistered and on-site payment" line (which moves a little more 237 slowly); and the "registration and on-site payment" line (take a 238 guess). 240 Registration is open all week. However, the Secretariat highly 241 recommendeds that attendees arrive for early registration, beginning 242 at 6:00 P.M. (meeting local time), on the Sunday before the meeting. 243 Not only will there be fewer people, but there will also be a 244 reception at which people can get a byte to eat. If the registration 245 lines are long, one can eat first and try again when the lines are 246 shorter. Newcomers are encouraged to attend the IETF Orientation on 247 Sunday at 4:30 P.M. 249 Registered attendees (and there isn't any other kind) receive a 250 Registration Packet. It contains a general orientation sheet, the 251 At-A-Glance sheet, a list of Working Group acronyms, the most recent 252 Agenda, and a name tag. The At-A-Glance is a very important 253 reference and is used throughout the week. It contains Working 254 Group/BOF room assignments and a map of room locations. Attendees 255 who prepaid will also find their receipt in their packet. 257 Dress Code 259 Since attendees must wear their name tags, they must also wear 260 shirts. Pants are also highly recommended. Seriously though, many 261 newcomers are often embarrassed when they show up Monday morning in 262 suits, to discover that everybody else is wearing T-shirts, jeans 263 (shorts, if weather permits) and sandals. There are those in the 264 IETF who refuse to wear anything other than suits. Fortunately, they 265 are well known (for other reasons), so they are forgiven this 266 particular idiosyncrasy. 268 The general rule is "dress for the weather." 270 Seeing Spots Before Your Eyes 272 Some of the people at the IETF will have a little colored dot on 273 their name tags. A few people have more than one. These dots 274 identify people who are silly enough to volunteer to do a lot of 275 extra work. The colors have the following meanings: 277 red - IAB member 278 yellow - IESG member 279 blue - Working Group/BOF chair 280 green - Local host 282 Local hosts are the people who can answer questions about the 283 terminal room, and restaurants and points of interest in the area. 285 It is important that newcomers to the IETF not be afraid to strike up 286 conversations with people who wear these dots. If the IAB and IESG 287 members, and Working Group and BOF chairs, didn't want to talk to 288 anybody, they wouldn't be wearing the dots in the first place. 290 To make life simpler for the Secretariat, Registration Packets are 291 also coded with little colored dots. These are only for Secretariat 292 use, so the nobody else needs to worry about them. 294 Terminal Room 296 One of the most important (depending on your point of view) things 297 the local host does is provide Internet access to the meeting 298 attendees. In general, the connectivity is excellent. This is 299 entirely due to the Olympian efforts of the local hosts, and their 300 ability to beg, borrow and steal. The people and companies who 301 donate the equipment, services, and time are to be heartily 302 congratulated and thanked. 304 While preparation far in advance of the meeting is encouraged, there 305 may be some unavoidable "last minute" things which can be 306 accomplished in the terminal room. 308 Social Event 310 Another of the most important things organized and managed by the 311 local hosts is the IETF social event. The social event has become 312 something of a tradition at the IETF meetings. It has been 313 immortalized by Marshal Rose with his reference to "many fine lunches 314 and dinners" [ROSE], and by Claudio Topolcic and his wife with their 315 rendition of "Nerds in Paradise" on a pink T-shirt. 317 Newcomers to the IETF are encouraged to attend the social event. 318 Everyone is encouraged to wear their name tags. The social event is 319 designed to give people a chance to meet on a social, rather than 320 technical, level. 322 Sometimes, the social event is a computer or high-tech related event. 323 At the Boston IETF, for example, the social was dinner at the 324 Computer Museum. Other times, the social might be a dinner cruise or 325 a trip to a Fine Arts gallery. 327 Agenda 329 The Agenda for the IETF meetings is a very fluid thing. It is sent, 330 in various forms, to the IETF announcement list three times prior to 331 the meeting. The final Agenda is included in the Registration 332 Packets. Of course, "final" in the IETF doesn't mean the same thing 333 as it does elsewhere in the world. The final Agenda is simply the 334 version that went to the printers. 336 The Secretariat will announce Agenda changes during the morning 337 plenaries. Changes will also be posted on the bulletin board near 338 the IETF Registration Table (not the hotel registration desk). 340 Assignments for breakout rooms (that's where the Working Groups and 341 BOFs meet) and a map showing the room locations make up the At-A- 342 Glance sheet (included in the Registration Packets). Room 343 assignments are as flexible as the Agenda. Some Working Groups meet 344 multiple times during a meeting and every attempt is made to have a 345 Working Group meet in the same room each session. Room assignment 346 changes are not necessarily permanent for the week. Always check the 347 At-A-Glance first, then the bulletin board. When in doubt, check 348 with a member of the Secretariat at the Registration Table. 350 Other General Things 352 The opening Plenary on Monday morning is the most heavily attended 353 session. It is where important introductory remarks are made, so 354 people are encouraged to attend. 356 The guy wearing the suit is probably Vint Cerf, the President of the 357 Internet Society and an IAB member. If you see a guy doing a strip 358 tease out of a suit, it's definitely Vint (but don't come just to see 359 him do it again; he's only done it once in the Internet's 20 year 360 history). 362 The IETF Secretariat, and IETFers in general, are very approachable. 363 Never be afraid to approach someone and introduce yourself. Also, 364 don't be afraid to ask questions, especially when it comes to 365 acronyms! 367 Hallway conversations are very important. A lot of very good work 368 gets done by people who talk together between meetings and over 369 lunches and dinners. Every minute of the IETF can be considered work 370 time (much to some people's dismay). 372 It's unwise to get between a hungry IETFer (and there isn't any other 373 kind) and coffee break brownies and cookies, no matter how 374 interesting a hallway conversation is. 376 IETFers are fiercely independent. It's always safe to question an 377 opinion and offer alternatives, but don't expect an IETFer to follow 378 an order. 380 The IETF, and the plenary sessions in particular, are not places for 381 vendors to try to sell their wares. People can certainly answer 382 questions about their company and its products, but bear in mind that 383 the IETF is not a trade show. 385 Registration Bullets 387 Registration is such an important topic, that it's in this RFC twice! 388 This is the "very important registration bullets" section. 390 o To attend an IETF meeting: you have to register and you have to 391 pay the registration fee. 393 o All you need to do to be registered is to send in a completed 394 Registration Form. 396 o You may register by mail, email or fax. Email and fax 397 registration forms will be accepted until 1:00 P.M. ET on the 398 Friday before the meeting. 400 o You may preregister and pay, preregister and pay later, 401 preregister and pay on-site, or register and pay on-site. 403 o To get the lower registration fee, you must register by the early 404 registration deadline (about one month before the meeting). You 405 can still pay later or on-site. 407 o If you don't register by the early registration deadline, a late 408 fee is added. 410 o Everyone pays the same fees. There are no education or group 411 discounts. There are no discounts for attending only part of the 412 week. 414 o Register only ONE person per registration form. Substitutions are 415 NOT allowed. 417 o You may register then pay later, but you may not pay then register 418 later. Payment MUST be accompanied by a completed registration 419 form. 421 o Purchase orders are NOT accepted. DD Form 1556 IS accepted. 423 o Refunds are subject to a $20 service charge. Late fees will not 424 be refunded. 426 o The registration fee covers a copy of the meeting's Proceedings, 427 Sunday evening reception (cash bar), a daily continental 428 breakfast, and two daily coffee breaks. 430 Mailing Lists and Archives 432 As previously mentioned, the IETF announcement and discussion mailing 433 lists are the central mailing lists for IETF activities. However, 434 there are many other mailing lists related to IETF work. For 435 example, every Working Group has its own discussion list. In 436 addition, there are some long-term technical debates which have been 437 moved off of the IETF list onto lists created specifically for those 438 topics. It is highly recommended that everybody follow the 439 discussions on the mailing lists of the Working Groups which they 440 wish to attend. The more work that is done on the mailing lists, the 441 less work that will need to be done at the meeting, leaving time for 442 cross pollination (i.e. attending Working Groups outside one's 443 primary area of interest in order to broaden one's perspective). 445 The mailing lists also provide a forum for those who wish to follow, 446 or contribute to, the Working Groups' efforts, but cannot attend the 447 IETF meetings. 449 All IETF discussion lists have a "-request" address which handles the 450 administrative details of joining and leaving the list. It is 451 generally frowned upon when such administrivia appears on the 452 discussion mailing list. 454 Most IETF discussion lists are archived. That is, all of the 455 messages sent to the list are automatically stored on a host for 456 anonymous FTP access. To find out where a particular list is 457 archived, send a message to the list's "-request" address, NOT to the 458 list itself. 460 Important Email Addresses 462 There are some important IETF email addresses with which everyone 463 should be familiar. They are all located at "nri.reston.va.us" (e.g. 464 "ietf-info@nri.reston.va.us"). 466 o ietf-info general queries about the IETF- 467 Greg Vaudreuil, Megan Davies and Cynthia Clark 469 o ietf-rsvp queries about meeting locations and fees, 470 emailed Registration Forms- 471 Debra Legare 473 o proceedings queries about previous Proceedings availability, 474 orders for copies of the Proceedings- 475 Debra Legare 477 o ietf-announce-request 478 requests to join/leave IETF announcement list- 479 Cynthia Clark 481 o ietf-request requests to join/leave IETF discussion list- 482 Cynthia Clark 484 o internet-drafts Internet-Draft submissions- 485 Cynthia Clark 487 o iesg-secretary Greg Vaudreuil 489 IETF Proceedings 491 The IETF Proceedings are compiled in the two months following each 492 IETF meeting. The Proceedings usually start with a message from 493 Phill Gross, the Chair of the IETF. Each contains the final 494 (hindsight) Agenda, an IETF overview, a report from the IESG, Area 495 and Working Group reports, network status briefings, slides from the 496 protocol and technical presentations, and the attendees list. The 497 attendees list includes an attendee's name, affiliation, work phone 498 number, work fax number, and email address, as provided on the 499 Registration Form. 501 A copy of the Proceedings will be sent to everyone who registered for 502 the IETF. The cost is included in the registration fee. The 503 Proceedings are sent to the mailing addresses provided on the 504 Registration Forms. 506 For those who could not attend a meeting, but would like a copy of 507 the Proceedings, send a check for $35 (made payable to CNRI) to: 509 Corporation for National Research Initiatives 510 Attn: Accounting Department - IETF Proceedings 511 1895 Preston White Drive, Suite 100 512 Reston, VA 22091 514 Please indicate which meeting Proceedings you would like to receive 515 by specifying the meeting date (e.g. July 1992) or meeting number and 516 location (e.g. 24th meeting in Boston). Availability of previous 517 meeting Proceedings is limited, so check BEFORE sending payment. 519 Be Prepared 521 This topic cannot be stressed enough. As the IETF grows, it becomes 522 more and more important for attendees to arrive prepared for the 523 Working Groups meetings they plan to attend. This doesn't apply only 524 to newcomers; everybody should be prepared to make the most out of 525 the week. 527 Being prepared means having read the documents which the Working 528 Group or BOF Chair has distributed. It means having followed the 529 discussions on the Working Group's mailing list or having reviewed 530 the archives. For the Working Group/BOF Chairs, it means getting all 531 of the documents out early enough (i.e. several weeks) to give 532 everybody time to read them. It also means announcing an agenda and 533 sticking with it. 535 At the Chair's discretion, some time may be devoted to bringing new 536 Working Group attendees up to speed. In fact, long lived Working 537 Groups have occasionally held entire sessions which were introductory 538 in nature. As a rule, however, a Working Group is not the place to 539 go for training. Observers are always welcome, but they must realize 540 that the work effort cannot be delayed for education. Anyone wishing 541 to attend a Working Group for the first time might seek out the Chair 542 prior to the meeting and ask for some introduction. 544 Another thing, for everybody, to consider is that Working Groups go 545 through phases. In the initial phase (say, the first two meetings), 546 all ideas are welcome. The idea is to gather all the possible 547 solutions together for consideration. In the development phase, a 548 solution is chosen and developed. Trying to reopen issues which were 549 decided more than a couple of meetings back is considered bad form. 550 The final phase (the last two meetings) is where the "spit and 551 polish" are applied to the architected solution. This is not the 552 time to suggest architectural changes or open design issues already 553 resolved. It's a bad idea to wait until the last minute to speak out 554 if a problem is discovered. This is especially true for people whose 555 excuse is that they hadn't read the documents until the day before a 556 comments period ended. 558 Time at the IETF meetings is a precious thing. Working Groups are 559 encouraged to meet between IETF meetings, either in person or by 560 video or telephone conference. Doing as much work as possible over 561 the mailing lists would also reduce the amount of work which must be 562 done at the meeting. 564 RFCs and Internet-Drafts 566 Originally, RFCs were just what the name implies; they were requests 567 for comments. The early RFCs were messages between the ARPANET 568 architects about how to resolve certain problems. Over the years, 569 RFCs became more formal. It reached the point that they were being 570 cited as standards, even when they weren't. 572 Internet Experiment Notes (IEN) were created to become a new informal 573 document series about the early experimental work on TCP and IP. It 574 was thought that having "Notes" as part of the name would prevent 575 them from being cited as standards. As the work matured, the 576 documentation was done as RFCs. 578 RFCs continue to be the important documents about the Internet; there 579 are now two special sub-series within the RFCs: FYIs and STDs. The 580 For Your Information RFC sub-series was created to document overviews 581 and things which are introductory. Frequently, FYIs are created by 582 the IETF User Services Area. The STD RFC sub-series is new. It was 583 created to identify those RFCs which do specify full Internet 584 Standards. RFCs of every type have an RFC number by which they are 585 indexed and by which they can be retrieved. FYIs and STDs have FYI 586 numbers and STD numbers, respectively, in addition to RFC numbers. 587 This makes it easier for a new Internet user, for example, to find 588 all of the helpful, informational documents, by looking in the FYI 589 index. In addition, FYI and STD numbers never change across a 590 document revision, while the RFC number does. 592 Internet-Drafts (I-D) are working documents of the IETF. Any group 593 (e.g. Working Group, BOF) or individual may submit a document for 594 distribution as an I-D. An I-D is valid for six months. Recent 595 guidelines require that an expiration date appear on every page of an 596 I-D. An I-D may be updated, replaced or obsoleted at any time. It 597 is not appropriate to use I-Ds as reference material or to cite them, 598 other than as a "working draft" or "work in progress". 600 For additional information, read the following documents: 602 o Request for Comments on Request for Comments [RFC1111] 603 o F.Y.I. on F.Y.I: Introduction to the F.Y.I notes [RFC1150] 604 o Introduction to the STD Notes [RFC1311] 605 o Guidelines to Authors of Internet Drafts [GAID] 606 o The Internet Activities Board [RFC1160] 607 o The Internet Standards Process [RFC1310] 608 o IAB Official Protocol Standards [STD1] 610 Frequently Asked Questions (and Their Answers) 612 Q: My Working Group moved this morning. Where is it now? 613 A: Not all room assignment changes are permanent. Check the At-A- 614 Glance sheet and the message board for announcements. 616 Q: Where is Room A? 617 A: Check the map on the At-A-Glance sheet. An enlarged version is on 618 the bulletin board. 620 Q: Where can I get a copy of the Proceedings? 621 A: The Proceedings are automatically sent to each attendee about two 622 months after the meeting. 624 Q: Where is lunch served? 625 A: The meeting does not include lunch or dinner. Ask a local host 626 (somebody with a green dotted badge) for a recommendation. 628 Q: Where are the receipts for the social event? 629 A: The social is not managed by the IETF Secretariat. Ask a local 630 host. 632 Pointers to Useful Documents and Files 634 This is a list of documents and files that provide useful information 635 about the IETF meetings, Working Groups, and documentation. These 636 files reside in the "ietf" directory on the Anonymous FTP sites 637 listed below. Files with names beginning with "0" (zero) pertain to 638 IETF meetings. These may refer to a recently held meeting if the 639 first announcement of the next meeting has not yet been sent to the 640 IETF mailing list. Files with names beginning with "1" (one) contain 641 general IETF information. This is only a partial list of the 642 available files. 644 o 0mtg-agenda.txt Agenda for the meeting 645 o 0mtg-at-a-glance.txt Logistics information for the meeting 646 o 0mtg-rsvp.txt Meeting registration form 647 o 0mtg-sites.txt Future meeting sites and dates 648 o 0mtg-traveldirections.txt Directions to the meeting site 650 o 1directories.txt The IETF Shadow directory locations and 651 contents. 652 o 1id-guidelines.txt Guidelines to Authors of Internet-Drafts 653 Contains information on writing and 654 submitting I-Ds. 655 o 1ietf-description.txt Short description of the IETF and IESG, 656 including a list of Area Directors. 657 o 1nonwg-discuss.txt A list of mailing lists created to 658 discuss specific IETF issues. 659 o 1proceedings-request.txt A Proceedings order form for the 660 current and previous meetings 661 o 1wg-summary.txt List of all Working Groups, by Area, 662 including the name and address of the 663 chairperson, and the mailing list 664 address. 666 Additionally, the charters and minutes of the Working Groups and BOFs 667 are archived in the "ietf" directory. 669 All of these documents are available by anonymous FTP from the 670 following sites: 672 o DDN NIC Address: nic.ddn.mil (192.112.36.5) 673 o East Coast (US) Address: nnsc.nsf.net (128.89.1.178) 674 o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) 675 o Pacific Rim Address: munnari.oz.au (128.250.1.21) 676 o Europe Address: nic.nordu.net (192.36.148.17) 678 The files are also available via email from various mail servers. To 679 to get the agenda and meeting summary from the mail server at SRI 680 International, for example, you would send the following message: 682 To: mail-server@nisc.sri.com Message header 683 Subject: anything you want 685 send 0mtg-agenda.txt Body of the message 686 send 0mtg-at-a-glance.txt 688 Residing on the same archive sites are the RFCs and Internet-Drafts. 689 They are in the "rfc" and "internet-drafts" directories, 690 respectively. The file "rfc-index.txt" contains the latest 691 information about the RFCs (e.g. which have been obsoleted by which). 692 In general, only the newest version of an Internet-Draft is 693 available. 695 Mail servers can also be used to retrieve RFCs and I-Ds. To use 696 SRI's mail server to get an RFC, simply include a "send command" in 697 the body of the message for the desired RFC. For example: 699 send rfc1150 701 or use a special RFC shorthand: 703 rfc 1150 705 For Internet-Drafts, include the name (yes, they are very long) in a 706 "send" command line. For example: 708 send draft-ietf-ripv2-mibext-03.txt 710 RFCs may also be retrieved, using email, from ISI's RFC-Info server 711 at "rfc-info@isi.edu". To get a specific RFC, include the following 712 in the body of the message: 714 Retrieve: RFC 715 Doc-ID: RFC0951 717 This example would cause a copy of RFC 951 (the leading zero in the 718 Doc-ID is required) to be emailed to the requestor. 720 To get a list of available RFCs which match certain criteria, include 721 the following in the body of the message: 723 LIST: RFC 724 Keywords: Gateway 726 This example would email a list of all RFCs with "Gateway" in the 727 title, or as an assigned keyword, to the requestor. 729 To get a copy of the RFC-Info manual: 731 HELP: Manual 733 To get information on other ways to get RFCs: 735 HELP: ways_to_get_rfcs 737 IETF Area Abbreviations 739 APP Applications 740 INT Internet Services 741 MGT Network Management 742 OPS Operational Requirements 743 OSI OSI Integration 744 RTG Routing 745 SEC Security 746 TSV Transport and Services 747 USV User Services 749 Acronyms 751 :-) Smiley face 752 ANSI American National Standards Institute 753 ARPANET Advanced Research Projects Agency Network 754 AS Autonomous System 755 ATM Asynchronous Transfer Mode 756 BGP Border Gateway Protocol 757 BOF Birds Of a Feather 758 BSD Berkeley Software Distribution 759 BTW By The Way 760 CCIRN Coordinating Committee for Intercontinental Research Networks 761 CNI Coalition for Networked Information 762 CREN The Corporation for Research and Educational Networking 763 DARPA Defense Advanced Research Projects Agency 764 DDN Defense Data Network 765 DISA Defense Information Systems Agency 766 EGP Exterior Gateway Protocol 767 FAQ Frequently Asked Question 768 FARNET Federation of American Research NETworks 769 FIX Federal Information Exchange 770 FNC Federal Networking Council 771 FQDN Fully Qualified Domain Name 772 FYI For Your Information (RFC) 773 GOSIP Government OSI Profile 774 IAB Internet Architecture Board 775 IANA Internet Assigned Numbers Authority 776 I-D Internet-Draft 777 IEN Internet Experiment Note 778 IESG Internet Engineering Steering Group 779 IETF Internet Engineering Task Force 780 IGP Interior Gateway Protocol 781 IMHO In My Humble Opinion 782 IMR Internet Monthly Report 783 IR Internet Registry 784 IRSG Internet Research Steering Group 785 IRTF Internet Research Task Force 786 ISO International Organization for Standardization 787 ISOC Internet Society 788 ISODE ISO Development Environment 789 MIB Management Information Base 790 MIME Multipurpose Internet Mail Extensions 791 NIC Network Information Center 792 NIS Network Information Services 793 NIST National Institute of Standards and Technology 794 NOC Network Operations Center 795 NREN National Research and Education Network 796 NSF National Science Foundation 797 OSI Open Systems Interconnection 798 PEM Privacy Enhanced Mail 799 PTT Postal, Telegraph and Telephone 800 RARE Reseaux Associes pour la Recherche Europeenne 801 RBOC Regional Bell Operating Company 802 RFC Request For Comments 803 RIPE Reseaux IP Europeenne 804 SIG Special Interest Group 805 STD Standard (RFC) 806 TLA Three Letter Acronym 807 TTFN Ta-Ta For Now 808 UTC Universal Time Coordinated 809 WG Working Group 810 WRT With Respect To 811 WYSIWYG What You See is What You Get 813 References 815 GAID "Guidelines to Authors of Internet Drafts", 816 1id-guidelines.txt. 818 ROSE Rose, Marshall T., The Open Book: A Practical Perspective on 819 OSI, 651 pgs., Prentice Hall, Englewood Cliffs, NJ, 1989. 821 RFC1111 Postel, J., "Request for Comments on Request for Comments", 822 RFC 1111, USC/Information Sciences Institute, August 1989. 824 RFC1150 Malkin, G., J. Reynolds, "F.Y.I. on F.Y.I.", RFC 1150 (FYI 825 1), Proteon, USC/Information Sciences Institute, March 1990. 827 RFC1160 Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May 828 1990. 830 RFC1310 Chapin, Lyman, "The Internet Standards Process", RFC 1310, 831 Internet Activities Board, March 1992. 833 RFC1311 Postel, J., "Introduction to the STD Notes", RFC 1311, 834 USC/Information Sciences Institute, March 1992. 836 STD1 Postel, J., "IAB Official Protocol Standards", STD 1 837 (currently RFC 1360), Internet Architecture Board, September 838 1992. 840 Security Considerations 842 This section intentionally left blank. 844 Author's Address 846 Gary Scott Malkin 847 Xylogics, Inc. 848 53 Third Avenue 849 Burlington, MA 01803 851 Phone: (617) 272-8140 852 EMail: gmalkin@Xylogics.COM