Network Working Group S. Moonesamy Internet-Draft Intended Status: Informational Expires: December 11, 2012 June 9, 2012 The Internet Engineering Task Force: A guide for newcomers draft-moonesamy-ietf-newcomers-00 Abstract This document describes the inner workings of Internet Engineering Task Force (IETF). It is an informal guide for newcomers to the IETF. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Moonesamy Expires December 11, 2012 [Page 1] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials,this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. About this document . . . . . . . . . . . . . . . . . . . . 4 2. What Is the IETF . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Note Well . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Internet Architecture Board (IAB) . . . . . . . . . . . . . 5 3.2. Internet Engineering Steering Group (IESG) . . . . . . . . 5 3.2.1. Working Groups . . . . . . . . . . . . . . . . . . . . 6 3.4 Internet Research Task Force (IRTF) . . . . . . . . . . . . 7 4. Participating in the IETF . . . . . . . . . . . . . . . . . . . 7 4.1. IETF Mailing Lists . . . . . . . . . . . . . . . . . . . . 8 5. IETF Meetings . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Planning your week . . . . . . . . . . . . . . . . . . . . 10 5.3.1. Dress Code . . . . . . . . . . . . . . . . . . . . . . 11 5.3.2. Social Event . . . . . . . . . . . . . . . . . . . . . 11 5.3.3. Working Group Sessions . . . . . . . . . . . . . . . . 11 5.3.4. Birds of a Feather (BOF) . . . . . . . . . . . . . . . 12 5.4. Proceedings . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Where Do I Fit In . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Newcomers . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. IT Managers . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Network Operators and ISPs . . . . . . . . . . . . . . . . 14 6.4. Networking Hardware and Software Vendors . . . . . . . . . 15 6.5. Academics . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.6. Press Coverage . . . . . . . . . . . . . . . . . . . . . . 15 7. Getting an RFC Published . . . . . . . . . . . . . . . . . . . 16 7.1. Letting Go Gracefully . . . . . . . . . . . . . . . . . . . 17 7.2. Internet-Draft . . . . . . . . . . . . . . . . . . . . . . 18 7.2.1 Internet-Draft Names . . . . . . . . . . . . . . . . . . 18 Moonesamy Expires December 11, 2012 [Page 2] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 7.2.2. Writing an Internet-Draft . . . . . . . . . . . . . . . 19 7.2.2.1. Security Considerations . . . . . . . . . . . . . . 20 7.2.2.2. IANA Considerations . . . . . . . . . . . . . . . . 20 7.2.3. Submitting an Internet-Draft . . . . . . . . . . . . . 20 7.2.4. Last Call . . . . . . . . . . . . . . . . . . . . . . . 20 7.2.5. IESG Evaluation . . . . . . . . . . . . . . . . . . . . 21 8. Administrative Support . . . . . . . . . . . . . . . . . . . . 21 8.1. IETF Administrative Support Activity . . . . . . . . . . . 21 8.2. IETF Secretariat . . . . . . . . . . . . . . . . . . . . . 21 9. Organizational Relationships . . . . . . . . . . . . . . . . . 22 9.1. IETF Trust . . . . . . . . . . . . . . . . . . . . . . . . 22 9.2. Internet Society . . . . . . . . . . . . . . . . . . . . . 22 9.3. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . . 22 9.4. Internet Assigned Numbers Authority (IANA) . . . . . . . . 22 9.5. Liaisons between the IETF and other Standards Organizations . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Acronyms and Abbreviations Used . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Background The first IETF meeting was held in January 1986 at Linkabit in San Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in October 1986, was the first that vendors attended. The concept of Working Groups was introduced at the 5th IETF meeting at the NASA Ames Research Center in California in February 1987. The 7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the first meeting with more than 100 attendees. The 14th IETF meeting was held at Stanford University in July 1989. It marked a major change in the structure of the IETF. The structure of the IAB (then the Internet Activities Board, now the Internet Architecture Board), which until that time oversaw many "task forces", was changed, leaving it with only two: the IETF and the IRTF. The IRTF is tasked to consider long-term research problems in the Internet. The IETF also changed at that time. After the Internet Society (ISOC) was formed in January 1992, the IAB proposed to ISOC that the IAB's activities should take place under the auspices of the Internet Society. During INET92 in Kobe, Japan, the ISOC Trustees approved a new charter for the IAB to reflect the proposed relationship. The IETF met in Amsterdam, The Netherlands, in July 1993. This was the first IETF meeting held in Europe, and the US/non-US attendee Moonesamy Expires December 11, 2012 [Page 3] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 split was nearly 50/50. The IETF first met in Asia (in Adelaide, Australia) in 2000. 1.1. About this document Attendance at the Internet Engineering Task Force (IETF) meetings has grown phenomenally since the early years. When the meetings were small, it was relatively easy for a newcomer to understand how the IETF works. Nowadays a newcomer meets many more new people, some previously known only as the authors of documents or through email messages. This document describes several aspects of the IETF with the goal of explaining to newcomers how the IETF works. The acronyms and abbreviations used in this document are expanded in place and are explained in Appendix A. The RFCs cited as references provide more details about the IETF. 2. What Is the IETF The IETF is not a traditional standards organization although many specifications that are produced become standards [RFC2026][RFC6410]. The IETF is unusual in that it is not registered as an organization or incorporated in any country. It does not have members or a board of directors. The IETF is open to anyone; it does not charge any fees or has any requirements for participation. The closest thing there is to being an IETF member is by participating in the discussions on the IETF mailing lists. The IETF is made up of volunteers, many of whom meet three times a year at IETF meetings. Anyone may register for a meeting and then attend. Many of the attendees are new to the IETF at each meeting. Some of those go on to become regular attendees. The goal of the IETF is to make the Internet work better. The Mission Statement documented in RFC 3935 [RFC3935] describes what the IETF is trying to achieve. The IETF in no way runs the Internet. The IETF makes voluntary standards which are often adopted by Internet users. A summary of the IETF work and events of the last day is available at https://tools.ietf.org/dailydose/ 2.1. Note Well The "Note Well" (see http://www.ietf.org/about/note-well.html ) lays out the rules for IETF process and intellectual property rights. You should read it carefully because you are deemed to agree to the "Note Well" by participating in the IETF. Moonesamy Expires December 11, 2012 [Page 4] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 3. Hierarchy 3.1. Internet Architecture Board (IAB) The IAB [RFC2850] is responsible for keeping an eye on the "big picture" of the Internet. The IAB stays informed about important long-term issues in the Internet. It brings these topics to the attention of people it thinks should know about them. IAB members are selected for two-year positions by the IETF community. The IAB focuses on long-range planning and coordination among the various areas of IETF activity. It pays special attention to emerging activities in the IETF. When a new IETF Working Group is proposed, the IAB reviews its charter for architectural consistency and integrity. Even before the group is chartered, IAB members discuss new ideas with the people proposing them. The IAB sponsors and organizes the Internet Research Task Force and convenes invitational workshops that provide in-depth reviews of specific Internet architectural issues. Typically, the workshop reports make recommendations to the IETF community and to the Internet Engineering Steering Group (IESG). The IAB also approves the nominations of IESG members and acts acts as the appeals board for appeals against IESG. 3.2. Internet Engineering Steering Group (IESG) The IESG [RFC3710] is responsible for technical management of IETF activities and the Internet standards process. It administers the process. The IESG doesn't exercise much direct leadership, such as the kind you will find in many other standards organizations. As its name suggests, its role is to set directions rather than to give orders. The IESG gets IETF Working Groups (WGs) started and finished and makes sure that the Internet-Drafts that are about to become IETF RFCs are correct. The IESG consists of the Area Directors (ADs) appointed for two years. The process for choosing the members of the IAB and IESG is detailed in RFC 3777 [RFC3777]. The current Areas and abbreviations are shown below. Area Description ----------------------------------------------------------------- Applications (APP) Protocols seen by user programs such as email and the web General (GEN) IETF process and catch-all for WGs that don't fit in other Areas (which is Moonesamy Expires December 11, 2012 [Page 5] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 rare) Internet (INT) Different ways of moving IP packets and DNS information Operations and Operational aspects, network monitoring, Management (OPS) and configuration Real-time Delay-sensitive interpersonal Applications and communications Infrastructure (RAI) Routing (RTG) Getting packets to their destinations Security (SEC) Authentication and privacy Transport (TSV) Special services for special packets The IESG has a great deal of influence on whether Internet-Drafts become RFCs. IETF participants sometimes reverently ask Area Directors for their opinion on a particular subject. When asked for specific technical comments the Area Directors often defer to IETF participants whom they feel have more knowledge than they do on that topic. The entire IESG reviews each Internet-Draft that is proposed to become a RFC to help avoid having IETF protocols which are at odds with each other. For example, the result of one Working Group might clash with a technology developed in a Working Group from another Area. The Area Directors for a particular Area are expected to know more about the combined work of the Working Groups in that Area than anyone else. The IESG usually moves in a reactive fashion because of its high workload. 3.2.1. Working Groups The vast majority of the IETF's work is done in many Working Groups [RFC2418]; at the time of this writing, there are about 115 different Working Groups. Each Working Group has one or two chairs. A Working Group is really just a mailing list (see https://datatracker.ietf.org/wg/ ). Anyone can join the Working Group by subscribing to the mailing list. Each Working Group has a charter that the Working Group is supposed to follow. The charter states the scope of discussion for the Working Group, as well as its goals. The Working Group's mailing list and face-to-face meetings are supposed to focus on just what is in the charter and not to Moonesamy Expires December 11, 2012 [Page 6] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 wander off on other topics. The large majority of the discussion should be on the topics listed in the charter. Some Working Group charters specify what the Working Group will not do, particularly if there were some attractive but nebulous topics brought up during the drafting of the charter. The IESG usually approves most Working Group requests for Internet- Drafts to be published as RFCs. It may step in when something has gone wrong. The quality of the IETF standards comes both from the review they get in a Working Group and the scrutiny that they gets from the IESG. 3.4 Internet Research Task Force (IRTF) The Internet Research Task Force (IRTF) [RFC2014] has responsibility for organizing groups to investigate research topics related to the Internet protocols, applications, and technology. The products of a Research Group are research results that may be disseminated by publication in scholarly journals and conferences, as white papers for the community or as Informational RFCs. 4. Participating in the IETF Read - Review the Internet-Drafts in your area of expertise and comment on them in the Working Groups. Participate in the discussion in a friendly and helpful manner with the goal of improving the proposal. Listen much more than you speak. If you disagree, debate the technical issues: never attack the people. Implement - Write programs that use the current Internet standards. The standards aren't worth much unless they are available to Internet users. Implement even the minor standards, since they will become less minor if they appear in more software. Report any problems you find with the standards so that the standard can be clarified in later revisions. One of the oft-quoted tenets of the IETF is "running code wins", so you can help support the standards you want to become more widespread by creating more running code. You can help the development of protocols before they become standards by implementing (but not deploying) from I-Ds to ensure that the authors have done a good job. If you find errors or omissions, offer improvements based on your implementation experience. Write - Edit or co-author Internet-Drafts in your area of expertise. Do this for the benefit of the Internet community, not to get your name (or, even worse, your company's name) on a document. Authors of Internet-Drafts are subject to all kinds of technical and sometimes personal criticism. Receive it with equanimity and use it to improve your draft in order to produce the best and most interoperable Moonesamy Expires December 11, 2012 [Page 7] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 standard. 4.1. IETF Mailing Lists The IETF announcement mailing list (see https://www.ietf.org/mailman/listinfo/IETF-Announce ) is where all important information, RFC announcements and Last Calls are sent. The is IETF general discussion list (see https://www.ietf.org/mailman/listinfo/ietf ) where IETF participants comment about Internet-Drafts going through Last Call. Non- subscribers may have their postings to an IETF mailing list delayed until the messages are approved by the mailing list moderator. The IETF general discussion list is unmoderated. IETF participants generally post messages to it to express their opinions about issues affecting the IETF or the Internet. The IETF general discussion list is not a place for companies or individuals to solicit or advertise, as noted in the IETF Discussion List Charter [RFC3005]. The list have two "sergeants at arms" who keep an eye open for inappropriate postings. There is a process for banning persistent offenders from the list, but fortunately this is extremely rare. The IETF mailing lists represent the IETF participants at large. It is important to note that attending an IETF meeting does not mean you'll be automatically added to IETF mailing lists. It is worth noting that neither attendee names and addresses nor IETF mailing lists are ever offered for sale. 5. IETF Meetings The computer industry is rife with conferences, seminars, expositions, and all manner of other kinds of meetings. IETF face- to-face meetings are nothing like these. The meetings, held three times a year, are week-long gatherings whose primary goal is to reinvigorate the Working Groups to get their tasks done, and whose secondary goal is to promote a fair amount of mixing between the Working Groups and the Areas. The cost of the meetings is paid by the people attending and by the corporate host for each meeting. IETF meetings are of little interest to sales and marketing folks, but of high interest to engineers and developers. The general flow of an IETF meeting is that it begins with tutorials and an informal gathering on Sunday, and that there are WG and BoF sessions from Monday to Friday. A WG session lasts between one to two and a half hours. Some WGs have several sessions during the week. Moonesamy Expires December 11, 2012 [Page 8] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 There are two plenary sessions, one technical and one administrative, in the evenings during the week. The technical plenary is organized by the IAB and usually has one or two panels of experts on topics of interest across many WGs and Areas. The administrative plenary, organized by the IETF Chair, covers things like progress reports from the RFC Editor and announcements of upcoming meetings. The plenaries are a good time to share with the IESG and IAOC. Praise is welcome. It is more often a venue for people to raise their concerns or complain about the IETF. The IETF meets in North America, Europe and Asia approximately once a year in each region. The past few meetings have had about 1,200 attendees. There have been more than 83 IETF meetings so far, and a list of upcoming meetings is available on the IETF web pages, http://www.ietf.org/meeting/upcoming.html. Newcomers to IETF face-to-face meetings are often in a bit of shock. They expect them to be like other standards bodies or like computer conferences. Fortunately, the shock wears off after a day or two, and many new attendees get quite animated about how much fun they are having. Some IETF participants can be surprisingly rude, such as talking loudly during functions when someone is speaking at the microphone or pushing through a crowd to get to food or drinks. This type of anti-social behavior seems to be more common at IETF meetings than at computer conferences. Newcomers should be patient with the old folks; these folks sometimes provide good advice. One particular feature of IETF meetings is the use of wireless Internet connections throughout the meeting space. It is common to see people in a Working Group meeting apparently reading email or perusing the web during presentations they find boring. Sometimes they may be consulting the drafts under discussion, looking up relevant material online or following another WG meeting using instant messaging. 5.1. Registration To attend an IETF meeting, you have to register and pay a registration fee. The meeting site and advance registration are announced about two months ahead of the meeting. An announcement goes out via email to the IETF-announce mailing list, and information is posted on the IETF web site, http://www.ietf.org, that same day. You can register and pay on the web before the meeting or in person at the meeting. To get a lower registration fee, you must pay by the early registration deadline (about one week before the meeting). The registration fee covers all of the week's sessions, the Sunday evening welcome reception (cash bar), daily continental breakfasts, Moonesamy Expires December 11, 2012 [Page 9] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 and afternoon beverage and snack breaks. Registration is open throughout the week of the meeting. It is highly recommended that attendees arrive for early registration, usually beginning at noon on Sunday and continuing throughout the Sunday evening reception. The reception is a popular event where you can get a small bite to eat and socialize with other early arrivals. If you need to leave messages for other attendees, you can do so at the cork boards that are often near the registration desk. These cork boards will also have last-minute meeting changes and room changes. You can also turn in lost-and-found items to the registration desk. At the end of the meeting, anything left over from the lost-and-found will usually be turned over to the hotel or brought back to the IETF Secretariat's office. The IETF registration desk is often a convenient place to arrange to meet people. If someone says "meet me at registration", you should clarify if they mean the IETF registration desk, or the hotel registration desk. This has been a common cause of missed connections. 5.2. Agenda The agenda for the IETF meetings is a very fluid thing. It is available on the web starting a few weeks before the meeting. Some Working Groups meet multiple times during a meeting. The final agenda is simply the version that went to the printer. A map showing the room locations are also shown on the agenda distributed at the meeting. Room assignments can change as the agenda changes. The Secretariat will post agenda changes on the bulletin board near the IETF registration desk (not the hotel registration desk). 5.3. Planning your week IETF Working Group sessions are scheduled from Monday morning through Friday afternoon. It is best to plan to be present the whole week, to benefit from cross-fertilization between Working Groups and from hallway discussions. As noted below, the agenda is fluid, and there have been many instances of participants missing important sessions due to last-minute scheduling changes after their travel plans were fixed. Being present the whole week is the only way to avoid this annoyance. If you cannot find meetings all week to interest you, you can still make the most of the IETF meeting by working between sessions. Most Moonesamy Expires December 11, 2012 [Page 10] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 IETF attendees carry laptop computers. It is common to see many in the hallways working during meeting sessions. There is often good wireless Internet coverage in many places of the meeting venue (restaurants, coffee shops, and so on), so catching up on email when not in meetings is a fairly common task for IETFers. 5.3.1. Dress Code Many newcomers are often embarrassed when they show up Monday morning in suits, to discover that everybody else is wearing T-shirts, jeans (shorts, if weather permits) and sandals. The general rule is "dress for the weather" (unless you plan to work so hard that you won't go outside, in which case, "dress for comfort" is the rule). People attending an IETF meeting usually wear a name tag. Members of the press wear orange-tinted badges. Some people have a little colored dot on their name tag. A few people have more than one. These dots identify people who have volunteered to do a lot of extra work. The colors have the meanings shown below. Color Meaning -------------------------------------- Blue Working Group/BOF chair Green Host group Red IAB member Yellow IESG member Orange Nominating Committee member Purple IAOC Pink IRSG member Teal RSE Local hosts are the people who can answer questions about restaurants and points of interest in the area. 5.3.2. Social Event The social event is sometimes high-tech-related event, or it might be in an art museum or a reception hall. Not all IETF meetings have social events. The social event is designed to give people a chance to meet on a social rather than technical level. Everyone is encouraged to wear their name tags and leave their laptops behind. 5.3.3. Working Group Sessions The heart of an IETF meeting is the Working Group sessions. Different WGs chairs have very different styles, so it is impossible to generalize how a WG meeting will feel. Even though nearly all WGs have agendas for their meetings, some meetings stick tightly to their Moonesamy Expires December 11, 2012 [Page 11] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 agenda while others are run more loosely. There are a few important things that are true for all WG sessions at an IETF meeting. Near the beginning of the meeting, the chair will pass around the "blue sheets", which are paper forms on which everyone prints their name and puts their email address. These are used for long-term archival purpose to show how many people came to a particular meeting and, in rare cases, exactly who showed up. The normal etiquette is to watch where the blue sheets came from and to pass them along in the same direction. When speaking in a meeting, you should always go to the microphones in the room. For controversial topics, there will be a line at the mic, but do not hesitate to be the first person at the mic if you have a question or a contribution to the discussion. The WG chair or presenter will indicate when you can speak. Although it would be easier to just raise your hand from where you are sitting, the mics perform a very useful task: they let the people listening remotely and in the room hear your question or comment. It is also expected that you will say your name at the mic so that the person taking minutes will know who is speaking. IETF procedures require all decisions to be confirmed "on the list" and you will often hear a Working Group chair say, "Let's take it to the list" to close a discussion. 5.3.4. Birds of a Feather (BOF) In order to form a Working Group, you need a charter and someone who is able to be chair. In order to get those things, you need to get people interested so that they can help focus the charter and convince an Area Director that the project is worthwhile. A face-to- face meeting is useful for this. A few WGs get started by an Area Director; most start after a face-to-face BOF because attendees have expressed interest in the topic. A Birds of a Feather (BOF) meeting has to be approved by the Area Director in the relevant Area before it can be scheduled. If you think you really need a new WG, approach an AD informally with your proposal and see what he or she thinks. The next step is to request a meeting slot at the next face-to-face meeting. Of course, you don't need to wait for that meeting to get some work done, such as setting up a mailing list and starting to discuss a charter. BOF sessions have a very different tone than do WG meetings. The purpose of a BOF is to make sure that a good charter with good milestones can be created and that there are enough people willing to do the work needed in order to create standards. Some BOFs have Moonesamy Expires December 11, 2012 [Page 12] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 Internet-Drafts already in process, whereas others start from scratch. An advantage of having a draft before the BOF is to help focus the discussion. On the other hand, having a draft might tend to limit what the other folks in the BOF want to do in the charter. It's important to remember that most BOFs are held in order to get support for an eventual Working Group, not to get support for a particular document. Some BOFs don't turn into WGs for a variety of reasons. A common problem is that not enough people can agree on a focus for the work. Another typical reason is that the work wouldn't end up being a standard -- if, for example, the document authors don't really want to relinquish change control to a WG. Only two meetings of a BOF can be scheduled on a particular subject; either a WG has to form or the topic should be dropped. 5.4. Proceedings IETF proceedings are compiled two months after each meeting and are available on the web. Be sure to look through a copy - the proceedings are filled with information about IETF that you're not likely to find anywhere else. For example, you'll find snapshots of most WG charters at the time of the meeting, giving you a better understanding of the evolution of any given effort. The proceedings sometimes start with an informative message. Each volume contains the final (hindsight) agenda, an IETF overview, Area and Working Group reports, and slides from the protocol and technical presentations. The Working Group reports and presentations are sometimes incomplete, if the materials haven't been turned in to the Secretariat in time for publication. An attendee list is also included, which contains names and affiliations as provided on the registration form. For information about obtaining copies of the proceedings, see the web listing at http://www.ietf.org/meeting/proceedings.html. 6. Where Do I Fit In The IETF is different things to different people. There are many people who have been very active in the IETF who have never attended an IETF meeting. Some people attend an IETF meeting to get a feel for the IETF. The following guidelines (based on stereotypes of people in various industries) might help you decide whether you actually want to come and, if so, what might be the best use of your Moonesamy Expires December 11, 2012 [Page 13] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 time at your first meeting. 6.1. Newcomers Newcomers are encouraged to attend the Newcomer's Orientation on Sunday afternoon which is designed for first-time attendees. The orientation is intended to provide introductory information about the IETF. The session covers the structure of the IETF and how the IETF works. Later in the afternoon is the Newcomer's Meet and Greet, which is only open to newcomers and WG chairs. This is a great place to try to find people knowledgeable in the areas in which you are interested. Feel free to approach any Working Group chair, not just those in your area, to either learn about their Working Group or to have them help find you someone in yours. Newcomers to the IETF not be afraid to strike up conversations with people who have dots on their name tag. If the IAB and IESG members and Working Group and BOF chairs didn't want to talk to anybody, they wouldn't be wearing the dots in the first place. IETF meetings are usually intense times for Area Directors. Talking to an Area Director during an IETF meeting will often lead to a request to send her or him email about two weeks later. When you start a hallway conversation with an Area Director (or even a Working Group chair, for that matter), it is often good to give them about 30 seconds of context for the discussion. 6.2. IT Managers An IETF meeting is not the places to go if your intention is to find out what will be hot in the Internet industry next year. You can safely assume that going to Working Group meetings will confuse you more than it will help you understand what is happening, or will be happening, in the industry. As an IT manager you might want to consider sending specific people who are responsible for technologies that are under development in the IETF. As these people read the current Internet-Drafts and the messages on the relevant Working Group lists, they will get a sense of whether or not their presence would be worthwhile for your company or for the Working Groups. 6.3. Network Operators and ISPs Running a network is hard enough without having to grapple with new protocols or new versions of the protocols with which you are already Moonesamy Expires December 11, 2012 [Page 14] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 dealing. If you work for the type of network that is always using the very latest hardware and software, and you are following the relevant Working Groups, you could certainly find participating in the IETF valuable. A fair amount of IETF work also covers many other parts of operations of ISPs and large enterprises, and the input of network operators is quite valuable to keep this work vibrant and relevant. Many of the best operations documents from the IETF come from real-world operators, not vendors and academics. 6.4. Networking Hardware and Software Vendors The image of the IETF being mostly ivory tower academics may have been true in the past, but the jobs of typical attendees are now in industry. In most areas of the IETF, employees of vendors are the ones writing the protocols and leading the Working Groups. If you create Internet hardware or software, and no one from your company has ever attended an IETF meeting, it behooves you to come to a meeting if for no other reason than to tell the others how relevant the meeting was or was not to your business. It isn't likely useful, for everyone from a technical department to go, particularly if they are not all reading the Internet-Drafts and following the Working Group mailing lists. Many companies have just a few designated meeting attendees who are chosen for their ability to do complete and useful trip reports. In addition, many companies have internal coordination efforts and a standards strategy. If a company depends on the Internet for some or all of its business, the strategy should probably cover the IETF. 6.5. Academics IETF meetings are often excellent places for computer science folks to find out what is happening in the way of soon-to-be-deployed protocols. Professors and grad students (and sometimes overachieving undergraduates) who are doing research in networking or communications can get a wealth of information by following Working Groups in their specific fields of interest. Wandering into different Working Group meetings can have the same effect as going to symposia and seminars in your department. Academics and Researchers are likely to be interested in IRTF activities (see http://www.irtf.org/ ). 6.6. Press Coverage Given that the IETF is one of the best-known bodies that is helping move the Internet forward, it's normal for the computer press (and even the trade press) to want to cover its actions. A small number of magazines have assigned reporters and editors to cover the IETF in Moonesamy Expires December 11, 2012 [Page 15] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 depth over a long period of time. The default press contact for the IETF is the IETF Administrative Director (IAD), who can be reached at . The main reason why a reporter might want to attend an IETF meeting is not to cover hot technologies (since that can be done in the comfort of your office by reading the mailing lists) but to meet people face-to-face. Unfortunately, the most interesting people are the ones who are also the busiest during the IETF meeting, and some folks have a tendency to run away when they see a press badge. IETF meetings are excellent places to meet and speak with document authors and Working Group chairs. This can be quite valuable for reporters who are covering the progress of protocols. Press errors can occur by saying that the IETF is considering something when in fact there is only an Internet-Draft. It's impossible to determine what will happen with a draft by looking at the draft or talking to the author of the draft. The press is not fully to blame for the mistake since they are usually alerted to the story by a company trying to get publicity for a protocol that they developed or at least support. Reporters who want to find out about what the IETF is doing on a particular topic would be well-advised to talk to more than one person who is active on that topic in the IETF. They should try to talk to the WG chair or Area Director in any case. Having a bit of press publicity for protocols that are almost near completion and will become significant in the industry in the next year can be a good thing. However, it is rare that a reporter can resist over-hyping a nascent protocol as the next big thing for the Internet. Such stories do much more harm than good, both for the readers of the article and for the IETF. 7. Getting an RFC Published One of the most common questions seasoned IETF participants hear from newcomers is, "How do I get an IETF standard published?" A much better question is, "Should I write an IETF standard?" since the answer is not always "yes". If you do decide to try to write a document that becomes an IETF standard, be warned that the overall process may be arduous, even if the individual steps are fairly straightforward. Very few people get through the process unscathed though. One of the first things you must decide is whether you want your document to be considered in a Working Group, of you want it to be considered as an individual (that is, non-WG) submission to the IETF. Even though most IETF standards come from Working Groups, some are Moonesamy Expires December 11, 2012 [Page 16] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 individual efforts: there might be no appropriate Working Group, or a potentially-appropriate Working Group might be to busy on other work to consider your idea. Every IETF standard, published as an RFC (Request for Comments), starts out as an Internet-Draft (often called an "I-D" or just "draft"). The basic steps for getting something published as an IETF standard are as follows: 1. Submit the document as an Internet-Draft 2. Convince IETF participants to review and comments on the draft. 3. Edit your draft based on the comments. 4. Repeat steps 1 through 3 a few times. 5. Ask an Area Director to sponsor the draft (if it's an individual submission). If the draft is an official Working Group product, the WG chair will help you with the publication process. 6. If the Area Director accepts to sponsor the draft, he or she will do an initial review, and maybe ask for updates before they move it forward. 7. Discuss concerns with the IESG members. Their concerns might be resolved with a simple answer or they might require additions or changes to the document. 7.1. Letting Go Gracefully Some people do not understand that is that they must give up change control of the protocol for it to be published as a RFC. That is, as soon as you propose that your protocol become an IETF standard, you must fully relinquish control of the protocol. If there is general agreement, parts of the protocol can be completely changed, whole sections can be ripped out, new things can be added, and the name can be changed. Some authors find it very hard to give up control of their pet protocol. If you are one of those people, don't even think about trying to get your protocol to become an IETF standard. On the other hand, if your goal is the best standard possible with the widest implementation, then you might find the IETF process to your liking. The change control on Internet standards doesn't end when the Moonesamy Expires December 11, 2012 [Page 17] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 protocol is put on the standards track. The protocol itself can be changed later for a number of reasons, the most common of which is that implementers discover a problem as they implement the standard. These later changes are also under the control of the IETF, not the editors of the standards document. IETF standards exist so that people will use them to write Internet programs that interoperate. They don't exist to document the ideas of their authors, nor do they exist so that a company can say, "We have an IETF standard". If a RFC only has one implementation (whereas two are required for it to advance on the standards track), it was probably a mistake to publish it in the first place. 7.2. Internet-Draft Internet-Drafts are tentative documents. They are meant for readers to comment on. The author decides which comments to incorporate in the draft. Internet-Drafts automatically expire from the six months. A person who doesn't understand RFCs (or is intentionally trying to fool people) may brag about having published an Internet-Draft; it takes no significant effort. When you submit an Internet-Draft, you give some publication rights to the IETF. This is so that your Internet-Draft is freely available to everyone who wants to read and comment on it. The rights you do and don't give to the IETF are described in BCP 78 [RFC5378], "IETF Rights in Contributions". Note that authors cannot take someone else's document and pass it off as their own; see BCP 78, section 5.6, point (a). 7.2.1 Internet-Draft Names There are some informal rules for Internet-Draft naming that have evolved over the years. The author's name is used as part of the filename. Internet-Drafts that revise existing RFCs often have draft names with "bis" in them, meaning "again" or "twice"; for example, a draft might be called "draft-author-rfc2345bis-00.txt". If an Internet-Draft is an official Working Group product, the name will start with "draft-ietf-" followed by the designation of the WG, followed by a descriptive word or two, followed by "00.txt". For example, a draft in the GROW WG about BGP might be named "draft-ietf- grow-bgp-00.txt". If it is not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "00.txt". After the first revision of a draft, the number in the filename is incremented; for instance, the second edition of the GROW draft named above would be "draft-smith-grow-bgp-01.txt". Moonesamy Expires December 11, 2012 [Page 18] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 The filename changes after one or more versions, such as when a personal effort is adopted as a Working Group draft; when a draft has its filename changed, the number reverts to -00. The WG chairs will let the Internet-Drafts administrator know the previous name of the draft when such a name change occurs so that the databases can be kept accurate. 7.2.2. Writing an Internet-Draft It is important that multiple readers and implementers of a standard have the same understanding of a document. To this end, information should be orderly and detailed. The reader is more likely to have general networking knowledge and experience rather than expertise in a particular protocol. An explanation of the protocol and its use will give the reader a reference point for understanding the protocol and where it fits in the Internet. The "Guide for Internet Standards Writers" [RFC2360] provides tips that will help you write a standard that leads to interoperability. For instance, it explains how to choose the right number of protocol options, how to respond to out- of-spec behavior, and how to show state diagrams. An Internet-Draft does not need to look exactly like an RFC. If you follow the I-D guidelines given at http://www.ietf.org/ietf/1id- guidelines.txt, chances are quite good that your draft will be fine. One way to make it more likely that developers will create interoperable implementations of standards is to be clear about what's being mandated in a specification. Early RFCs used all kinds of expressions to explain what was needed, so implementors didn't always know which parts were suggestions and which were requirements. As a result, standards writers in the IETF generally agreed to limit their wording to a few specific words with a few specific meanings. The "Key words for use in RFCs to Indicate Requirement Levels" are defined in RFC 2119 [RFC2119]. An Internet-Draft may contain two types of references; normative and informative. A normative reference is a reference to a document that must be followed in order to implement the standard. A informative reference is one that is helpful to an implementer but is not needed. An IETF standard may make a normative reference to any other standards-track RFC that is at the same standards level or higher, or to any "open standard" that has been developed outside the IETF. If you are writing an Internet-Draft and you know of a patent that applies to the technology you're writing about, don't list the patent in the document. Read the IETF IPR page at http://www.ietf.org/ipr and BCP 79 [RFC3979][RFC4879] and file an IPR disclosure. Intellectual property rights aren't mentioned in RFCs because RFCs Moonesamy Expires December 11, 2012 [Page 19] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 never change after they are published but knowledge of IPR can change at any time. There is a tool called "xml2rfc" available from http://xml.resource.org. It takes XML-formatted text and generates an Internet-Draft. 7.2.2.1. Security Considerations Every RFC requires a "Security Considerations" section. This section should describe any known vulnerabilities of the protocol, possible threats and mechanisms or strategies to address them. Don't gloss over this section -- in particular, don't say, "Here's our protocol, if you want security, just use IPsec". This won't do at all because it doesn't answer the question of how IPsec interacts with your protocol, and vice versa. See "Guidelines for Writing RFC Text on Security Considerations" [RFC3552] for more information on writing good security considerations sections. 7.2.2.2. IANA Considerations Many IETF protocols make use of values which are uniquely assigned to ensure consistent interpretation between independent implementations. These assignments are defined in the IETF Protocol Parameter Registries [RFC6220]. For historical reasons these registries are operated by IANA. If you are writing an Internet standard which needs an assignment, read the RFC ( https://www.iana.org/protocols/ ) which defines the registration requirements. Registration is generally done in the "IANA Considerations" [RFC5226] section of an Internet-Draft. 7.2.3. Submitting an Internet-Draft Internet-Drafts can be submitted at https://datatracker.ietf.org/submit/ The IETF Tools web pages ( http://tools.ietf.org/ ) has pointers to tools that will automate some of your work for the IETF. There is a very useful checking tool at http://tools.ietf.org/tools/idnits which can be used to help prevent the draft from being rejected due to errors in form and formatting. There is a list of common issues ( http://www.ietf.org/ID-Checklist.html ) that have been known to stop documents in the IESG. 7.2.4. Last Call The purpose of IETF Last Call is to get community-wide discussion on an Internet-Draft so the IESG determine whether it has IETF consensus. It is also a time when people in the Working Group who Moonesamy Expires December 11, 2012 [Page 20] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 feel that they weren't heard can make their comments to everyone. The IETF Last Call is at least two weeks for Working Group drafts and four weeks for individual submissions. The discussion for a Last Call is held on the IETF general discussion list and is open to everyone. IETF Last Call comments posted by people who have just read the draft for the first time can expose issues that IETF and Working Group regulars may have completely missed. It is generally considered bad form to send IETF Last Call comments on documents that you have not read, or to send comments but not be prepared to discuss your views. The IETF Last Call is not a vote. Campaigns aimed at getting people to post messages in support or opposition to a document usually backfire. 7.2.5. IESG Evaluation Any Area Director may record a "DISCUSS" ballot position against an Internet-Draft if he or she has serious concerns. If these concerns cannot be resolved by discussion, an override procedure is defined such that at least two IESG members must express concerns. This procedure helps to ensure that an Area Director's "pet peeve" cannot indefinitely block something. If the IESG approves the draft they ask the RFC Editor to publish it as a RFC. 8. Administrative Support 8.1. IETF Administrative Support Activity The IETF Administrative Support Activity (IASA) [RFC4071] provides the administrative structure required to support the IETF standards process and to support the IETF's technical activities. Within this activity is the office of the IETF Administrative Director (IAD) and the IETF Administrative Oversight Committee (IAOC). 8.2. IETF Secretariat A few people, who are part of the IETF Secretariat, are paid to provide day-to-day logistical support for the IETF, coordinate IETF meetings. The IETF Secretariat is also responsible for keeping the official Internet-Drafts directory up to date and orderly, maintaining the IETF web site, and for helping the IESG do its work. It provides various tools for use by the community and the IESG. The IETF Secretariat is under contract to IASA, which in turn is financially supported by the fees collected for attending the IETF meetings. Moonesamy Expires December 11, 2012 [Page 21] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 There is a list of e-mail addresses to contact ( https://www.ietf.org/contact-the-ietf.html ) the IETF Secretariat. 9. Organizational Relationships 9.1. IETF Trust The IETF Trust was set up in 2005 to have a stable and legally- identifiable entity for the IETF. The IETF Trust holds and licenses the intellectual property of the IETF. The members of the IETF Administrative Oversight Committee serve as IETF Trustees. You can find out more about the IETF Trust at their web site ( http://trustee.ietf.org ). 9.2. Internet Society The Internet Society (ISOC) provides insurance coverage for many of the people holding leadership positions in the IETF process and acts as a public relations channel for the times that one of the "I" groups wants to say something to the press. Since 2005 the Internet Society employs the IETF Administrative Director (IAD) who works full-time overseeing IETF meeting planning and operational aspects of the IETF Secretariat. 9.3. RFC Editor The RFC Editor [RFC4844] edits, formats, and publishes Internet- Drafts as RFCs, working in conjunction with the IESG. An important secondary role is to provide one definitive repository for all RFCs (see http://www.rfc-editor.org ). Once an RFC is published, it is never revised. If the specification it describes changes, the standard will be re-published in another RFC that "obsoletes" the first. Up through the end of 2009 the RFC Editor was a single entity. The function was split by the IAB into several roles that can be performed by different people or organizations. 9.4. Internet Assigned Numbers Authority (IANA) The Internet Assigned Numbers Authority (IANA) activities are currently performed by the Internet Corporation for Assigned Names and Numbers (ICANN). IANA services to the IETF are provided for free as specified in [RFC2860]. The IETF is not involved in domain name and IP address assignment functions. 9.5. Liaisons between the IETF and other Standards Organizations Moonesamy Expires December 11, 2012 [Page 22] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 The IETF tries to have cordial relationships with other standards organizations. The IETF has liaisons ( http://www.ietf.org/liaison ) with large standards organizations, including the ITU-T (the Telecommunication Standardization Sector of the International Telecommunication Union), the W3C (World Wide Web Consortium), the IEEE (the Institute of Electrical and Electronics Engineers) and the Unicode Consortium. Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications [RFC2850]. In practice, the IETF prefers liaisons to take place directly at Working Group level with formal relationships and liaison documents [RFC4053] in a backup role. 10. Acknowledgments This document contains a large amount of text from RFC 4677 which is is known as the Tao of the IETF. RFC 4677 was co-authored by Paul Hoffman and Susan Harris. Contributors include Brian Carpenter, Scott Bradner, Michael Patton, Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault, Russ Housley, the IETF Secretariat, members of the User Services Working Group, and members of the PESCI (Process Evolution Consideration for the IETF) design team. The original version of RFC 4677, published in 1994, was written by Gary Malkin. His knowledge of the IETF, insights, and unmatched writing style set the standard for this later revision, and his contributions to the RFC 4677 are also much appreciated. 11. References 11.1. Informative References [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, October 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, RFC 2360, June 1998. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. Moonesamy Expires December 11, 2012 [Page 23] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, November 2000. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February 2004. [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004. [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004. [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005. [RFC4071] Austein, R., Ed., and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005. [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. [RFC4879] Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5378] Bradner, S., Ed., and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, Moonesamy Expires December 11, 2012 [Page 24] INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012 November 2008. [RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., Huston, G., Ed., and Internet Architecture Board, "Defining the Role and Function of IETF Protocol Parameter Registry Operators", RFC 6220, April 2011. [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011. Appendix A. Acronyms and Abbreviations Used Some of the acronyms and abbreviations from this document are listed below. Term Meaning ----------------------------------------------------------------- AD Area Director BCP Best Current Practice BOF Birds of a Feather IAB Internet Architecture Board IAD IETF Administrative Director IANA Internet Assigned Numbers Authority IAOC IETF Administrative Oversight Committee IASA IETF Administrative Support Activity ICANN Internet Corporation for Assigned Names and Numbers I-D Internet-Draft IESG Internet Engineering Steering Group IETF Internet Engineering Task Force IPR Intellectual property rights IRTF Internet Research Task Force ISOC Internet Society PS Proposed Standard (RFC) RFC Request for Comments STD Standard (RFC) WG Working Group Authors' Addresses S. Moonesamy 76, Ylang Ylang Avenue Quatre Bornes Mauritius EMail: sm+ietf@elandsys.com Moonesamy Expires December 11, 2012 [Page 25]