Movatterモバイル変換


[0]ホーム

URL:


RFC 9592Retiring the Tao of the IETFJune 2024
ten Oever & WoodInformational[Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
9592
Obsoletes:
6722
Category:
Informational
Published:
ISSN:
2070-1721
Authors:
N. ten Oever
University of Amsterdam
G. Wood
IETF Administration LLC

RFC 9592

Retiring the Tao of the IETF

Abstract

This document retires and obsoletes the Tao of the IETF as an IETF-maintained document. This document also obsoletes RFC 6722, which describes the publication process of the Tao. Furthermore, this document describes the rationale for the retirement of the Tao. For archival purposes, the last version of the Tao is included in the appendix. Information that new participants need to engage in the work of the IETF will continue to be provided through the IETF website in a more timely and accessible manner. This is the way.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9592.

Copyright Notice

Copyright (c) 2024 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 (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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

1.Introduction

Since its publication as[RFC1391] in 1993, The "Tao of the IETF" ("Tao") has described the inner workings of IETF meetings and Working Groups, discussed organizations related to the IETF, and introduced the working processes to new participants. The Tao never was a formal IETF process document, but rather a community-developed and maintained informational overview. After the Tao was published as an RFC for 13 years, it was published as a webpage for over a decade following the process described in[RFC6722]. However, the Tao did not keep up with the changes in the processes of the community and the organization, and thereby ceased to be a reliable source of information. We gratefully want to acknowledge all the individuals who contributed to the Tao over the years. The changing nature of IETF participation, a better understanding of how to most effectively convey information to new participants, and experience with publishing the Tao as a webpage all suggest a new approach to collecting, updating, and communicating the information that new participants need to engage in the work of the IETF successfully. This document formally retires and obsoletes the "Tao of the IETF" as a single standalone document.

2.Reasons for Retirement

In short, the breadth of topics covered in the Tao, the unpredictable and different schedule for updates to the topics, and the high overhead for revising and reviewing the content did not match the needs or preferences of the intended audience of the Tao.

2.1.Infrequent Updates

The Tao was originally published as[RFC1391] in January 1993. In the following 17 years, four additional versions of the Tao were published as RFCs:

In August 2012,[RFC6722] was published to document the process for publishing the Tao as a webpage so that it could "be updated more easily." However, in the subsequent 11 years, only four additional versions were published. The length of the Tao meant that review and approval of the entire document took considerable effort and time, leading to very infrequent updates.

2.2.Unwieldy Format

The large, consolidated document format of the Tao made for a heavy investment by readers, in addition to the difficulty editors faced keeping pace with the changes required to keep it current. For example, the emergence of IETF Hackathon popularity with new participants prompted an update. However, that content was effectively buried in an already long document.

2.3.Changing Participation Modes

The original Tao aimed to welcome new participants to IETF meetings as attendance grew rapidly along with the growth of the Internet in the 1990s. As other avenues for initial participation in the IETF emerged over the ensuing decades, the main focus of the Tao remained on in-person meeting participation. For example, remote participation in IETF meetings has become a much more significant aspect in the past few years.

3.Going Forward

The content of the Tao has already been integrated into the website of the IETF, which is the main channel of communication for IETF newcomers and a general audience. The content is continuously kept up to date with a variety of media to serve different audiences. The IETF seeks to ensure that the website continues to address the needs of our ever-evolving community and potential newcomers.

3.1.New Communications Opportunities

The IETF and its community continuously seek to improve its communication to newcomers and existing participants alike. Examples of possible ways of doing this:

  • More focused guides, e.g., on IETF Hackathon participation, starting new work, etc.
  • Alternative formats, e.g., multiple shorter documents, on-demand video, podcasts, etc.
  • New channels for communications, e.g., blog posts, improved Datatracker, Slack, etc.

4.Conclusion

The coverage of a wide range of topics, the unpredictable and different schedule for updates to the topics, and the high overhead for revising and reviewing the content mean that the Tao required a lot of effort to maintain, was commonly out-of-date, and thus did not serve its intended purpose of informing the community and newcomers. Therefore, this document is the end of the road for "Tao of the IETF." The document is now retired. For archival reasons, the last version of the Tao can be found inAppendix A.

5.Security Considerations

This document has no security considerations.

6.IANA Considerations

This document has no IANA actions.

7.Informative References

[RFC1391]
Malkin, G.,"The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force",RFC 1391,DOI 10.17487/RFC1391,,<https://www.rfc-editor.org/info/rfc1391>.
[RFC1539]
Malkin, G.,"The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force",RFC 1539,DOI 10.17487/RFC1539,,<https://www.rfc-editor.org/info/rfc1539>.
[RFC1718]
IETF andG. Malkin,"The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force",RFC 1718,DOI 10.17487/RFC1718,,<https://www.rfc-editor.org/info/rfc1718>.
[RFC3160]
Harris, S.,"The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force",RFC 3160,DOI 10.17487/RFC3160,,<https://www.rfc-editor.org/info/rfc3160>.
[RFC4677]
Hoffman, P. andS. Harris,"The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force",RFC 4677,DOI 10.17487/RFC4677,,<https://www.rfc-editor.org/info/rfc4677>.
[RFC6722]
Hoffman, P., Ed.,"Publishing the "Tao of the IETF" as a Web Page",RFC 6722,DOI 10.17487/RFC6722,,<https://www.rfc-editor.org/info/rfc6722>.

Appendix A.Last Edition of the Tao

For archival purposes, the last edition of the Tao as published under the process described in[RFC6722], is included below. Note that several links to resources external to the Tao do not work at the time of publication of this RFC. Additionally, minor errors in the following text have been corrected.

Abstract

This document introduces you to the "ways of the IETF": it will convey the might and magic of networking people and packets in the Internet's most prominent standards body. In this document we describe the inner workings of IETF meetings and Working Groups, discuss organizations related to the IETF, and introduce the standards process. This is not a formal IETF process document but an informal and informational overview.

1 Introduction

The Internet Engineering Task Force (IETF) is the largest standard development organization (SDO) for the Internet. Since its early years, participation in the IETF has grown phenomenally. In-person attendance at face-to-face meetingsnow averages between 1000 and 1500 participants. At any given meeting, around 200 attendees arenewcomers (defined by the IETF as someone who has attended five or fewer meetings), and many of those go on to become regular participants. When the IETF was smaller, it was relatively easy for a newcomer to adjust. Today, however, a newcomer meets many more new people -- some previously known only as the authors of documents or thought-provoking email messages.

Of course, it's true that many IETF participants don't go to the face-to-facemeetings at all -- especially since the COVID-19 pandemic when meetings werecompletely online for a while. There are also many participants who solelyfocus on the mailing lists of various IETF Working Groups. Since the innerworkings of Working Groups can be hard for newcomers to understand, thisdocument provides the mundane bits of information that newcomers will need inorder to become active participants. The IETF website also has a lot ofnewcomer information in various formats.In this document we try to cover as much as possible in one place.

The IETF is always evolving. Although the principles in this document areexpected to remain consistent over time, practical details may wellhave changed by the time you read it; for example, a web-based tool may havereplaced an email address for requesting some sort of action.

Many types of IETF documentation are mentioned here. The IETF publishes itstechnical documentation as RFCs, still known by their historical termRequests for Comments. (Sometimes people joke that it stands forRequest for Compliance.) STDs are RFCs identified as "standards",and BCPs are RFCs that represent thoughts on Best Current Practices in theInternet. Both STDs and BCPs are also RFCs. For example,BCP 9 points to a collectionof RFCs that describe the IETF's standardization processes.SeeRFCs and Internet-Drafts for more details.

1.1 Acronyms and Abbreviations Used in the Tao

Some of the acronyms and abbreviations from this document are listed below.

Table 1
TermMeaning
ADArea Director
BCPBest Current Practice (a type of RFC)
BOFBirds of a Feather
IABInternet Architecture Board
IANAInternet Assigned Numbers Authority
IASAIETF Administrative Support Activity
ICANNInternet Corporation for Assigned Names and Numbers
I-DInternet-Draft
IESGInternet Engineering Steering Group
IPRIntellectual property rights
IRSGInternet Research Steering Group
IRTFInternet Research Task Force
ISOCInternet Society
RFCRequest for Comments
STDStandard (a type of RFC)
WGWorking Group

2 What is the IETF?

The IETF has no members and no dues; it is a loosely self-organized group of people who contribute to theengineering and evolution of Internet technologies. It is the principal bodyengaged in the development of new Internet standard specifications. The IETFis unusual in that it exists as a collection of meetings (both in-personand virtual) and online activities (such as email and pull request discussions),in which individuals voluntarily participate.

The IETF welcomes all interested individuals: IETF participants come from allover the world and from many different parts of the Internet industry. TheIETF conducts its work solely in English.SeeWhere do I fit in?for information about the ways that many peoplefit into the IETF.

Quoting fromRFC 3935: A Mission Statement for the IETF:"the overall goal of the IETF is to make the Internet work better.Its mission is to produce high quality, relevanttechnical and engineering documents that influence the way peopledesign, use, and manage the Internet in such a way as to make theInternet work better. These documents include protocol standards,best current practices, and informational documents of various kinds."

The ways to do that include the following:

  • Identifying and proposing solutions to pressing operational andtechnical problems in the Internet.

  • Specifying the development or usage of protocols and the near-termarchitecture to solve such technical problems for the Internet.

  • Making recommendations to the Internet Engineering Steering Group(IESG) regarding the standardization of protocols and protocol usagein the Internet.

  • Facilitating technology transfer from the Internet Research TaskForce (IRTF) to the wider Internet community.

  • Providing a forum for the exchange of information within the Internetcommunity among vendors, users, researchers, agency contractors,operators, and network managers.

RFC 3935 further states that the Internet isn't value-neutral, andneither is the IETF. The IETF wants the Internet to be useful forcommunities that share our commitment to openness and fairness. The IETFembraces technical concepts such as decentralized control, edge-userempowerment and sharing of resources, because those concepts resonate withthe core values of the IETF community. These concepts have little to do withthe technology that's possible, and much to do with the technology that theIETF chooses to create.

In many ways, the IETF runs on the beliefs of its participants. One of thefounding beliefs is embodied in an early quote about the IETF from DavidClark: "We reject kings, presidents and voting. We believe in rough consensusand running code." Another early quote that has become a commonly-held beliefin the IETF comes from Jon Postel: "Be conservative in what you send andliberal in what you accept."

There is no membership in the IETF. Anyone may sign up to working groupmailing lists, or register for a meeting and then attend. The closest thingthere is to being an IETF member is being a participant on the IETF orWorking Groupmailing lists. This is where the bestinformation about current IETF activities and focus can be found.

Of course, no organization can be as successful as the IETF is without havingsome sort of structure. In the IETF's case, that structure is provided byother supporting organizations, as described inRFC 2028: The OrganizationsInvolved in the IETF Standards Process.Please note that RFC 2028 is outdated and being revised.

TheIETF web site is the best source forinformation about upcoming IETF meetings and newcomer materials. The IETFDatatracker is the best source forinformation about Internet-Drafts, RFCs, and Working Groups.

One more thing that is important for newcomers: the IETF in no way "runs theInternet," despite what some people mistakenly might say. The IETF makesvoluntary standards that are often adopted by Internet users, networkoperators, and equipment vendors, and it thus helps shape the trajectory ofthe development of the Internet. But in no way does the IETF control, or evenpatrol, the Internet. If your interest in the IETF is because you want to bepart of the overseers, you may be badly disappointed by the IETF.A saying you will sometimes hear is, "we are not the protocol police."

2.1 Humble Beginnings

The first IETF meeting was held in January 1986 at Linkabit in San Diego,with 21 attendees. The 4th IETF, held at SRI in Menlo Park in October 1986,was the first that equipment vendors attended. The concept of Working Groupswas introduced at the 5th IETF meeting at the NASA Ames Research Center inCalifornia in February 1987. The 7th IETF, held at MITRE in McLean, Virginia,in July 1987, was the first meeting with more than 100 attendees.

After theInternet Society (ISOC) was formed in January 1992, the IABproposed to ISOC that the IAB's activities should take place under theauspices of the Internet Society. During INET92 in Kobe, Japan, the ISOCTrustees approved a new charter for the IAB to reflect the proposedrelationship.

The IETF met in Amsterdam, The Netherlands, in July 1993. This was the firstIETF meeting held in Europe, and the US/non-US attendee split was nearly50/50. The IETF first met in Oceania (in Adelaide, Australia) in 2000, thefirst meeting in Asia (in Yokohama, Japan) was in 2002, and the first meetingin Latin America (in Buenos Aires, Argentina) was in 2016. So far, the IETFhas never met in Africa.

The IETF currently has a "1-1-1" meeting policy where the goal is todistribute the meetings equally between North America, Europe, and Asia.This policy is mainly aimed at distributing the travel effort for theexisting IETF participants who physically attend meetings and fordistributing the timezone difficulty for those who participate remotely. TheIETF has also met in Latin America and Oceania, but these continents arecurrently not part of the 1-1-1 rotation schedule.More information on picking the venue and the meeting policy can be foundinRFC 8718: IETF Plenary Meeting Venue Selection ProcessandRFC 8719: High-Level Guidance for the Meeting Policy of the IETF.

Remote participation in IETF meetings has been growing significantly in thepast few years, thanks in part to the ongoing effort to improve the tools andprocesses used to facilitate this mode of participation.

2.2 The Hierarchy

2.2.1 The Internet Society (ISOC) and the IETF Administration LLC (IETF LLC)

The Internet Society (ISOC) is an international, non-profit, membershiporganization that supports and promotes the development of the Internet as aglobal technical infrastructure. The mission of ISOC is "to promote the opendevelopment, evolution, and use of the Internet for the benefit of all peoplethroughout the world." One of the ways that ISOC does this is through financialsupport of the IETF.

TheIETF Administration LLC (IETF LLC)is a "disregarded entity" of ISOC, which means it is treated asa branch or division for tax purposes. The IETF LLC has no role in theoversight or steering of the standards process, the appeal chain, theconfirming bodies for existing IETF and IAB appointments, the IRTF, or ISOC'smemberships in other organizations. Rather, the IETF LLC, as overseen by itsBoard of Directors, is responsible for staffing and contracts with placeslike hotels to host IETF meetings. Most of the day-to-day activitiesare delegated to the IETF Executive Director.

Responsibilities of the IETF LLC include:

  • Supporting the ongoing operations of the IETF, including meetings andnon-meeting activities.

  • Managing the IETF's finances and budget.

  • Raising money on behalf of the IETF.

  • Establishing and enforcing policies to ensure compliance with applicablelaws, regulations, and rules.

The IETF and ISOC continue to be strongly aligned on key principles. ISOCinitiatives related to the IETF continue to support participation in, anddeployment of, the standards created by the IETF.

2.2.2 Internet Engineering Steering Group (IESG)

The IESG is responsible for technical management of IETF activities and theInternet standards process. However, the IESG doesn't exercise much directleadership, such as the kind you will find in many other standardsorganizations. As its name suggests, its role is to set directions ratherthan to give orders. The IESG gets WGs started and finished, ratifies orsteers the output from the IETF's Working Groups (WGs), and makes sure thatnon-WG I-Ds that are about to become RFCs are correct.

Check theIESG web pages to findup-to-date information about IESG statements, I-Ds processed, RFCs published,and documents in Last Call, as well as the monthly IETF status reports.

The IESG consists of the Area Directors (ADs), who are selected by theNominations Committee (NomCom) and are appointed for two years. The processfor choosing the members of the IESG is detailed inBCP 10.

The current Areas and abbreviations are shown below, andmore details are onthe IETF web site.

Table 2
AreaDescription
Applications and Real-Time Area (art)Protocols seen by user programs, such as email and the web and delay-sensitive interpersonal communications
General (gen)IETF process, and catch-all for WGs that don't fit in other Areas (which is very few)
Internet (int)Different ways of moving IP packets and DNS information
Operations and Management (ops)Network management, AAA, and various operational issues facing the Internet
Routing (rtg)Getting packets to their destinations
Security (sec)Privacy, integrity, authentication, non-repudiation, confidentiality, and access control
Transport (tsv)Transport for large volumes of traffic at potentially high bandwidths

Because the IESG reviews all Internet-Drafts before they become RFCs, ADshave quite a bit of influence. The ADs for a particular Area are expected toknow more about the combined work of the WGs in that Area than anyone else.This is because the ADs actively follow the working groups for which they areresponsible and assist working groups and chairs with charter and milestonereviews. Some people, therefore, shy away from directly engaging with AreaDirectors. Don't -- they can be an important resource and help you findthe person or the answer that you're looking for. They are, however, oftenvery busy during meetings, and so an email to schedule a meeting can beuseful, or just ask your questions.

The entire IESG reviews each Internet-Draft (I-D or "draft") that is proposed to become an RFCand should be aware of general trends that can be gleaned from the collectivework products of the IETF. For IETF produced RFCs, as part of the document reviews, ADs place ballotsthat may contain comments on documents. The AD enters a position that may beYES,NO OBJECTION,DISCUSS,ABSTAIN, orRECUSE as the result oftheir review. Any AD may record aDISCUSS ballot position against a draftif they have serious concerns and would like to discuss these concerns.It is common for documents to be approved with one or twoYESballots, and the majority of the remaining IESG ballotingNO OBJECTION. AnIETF blog postprovides advice on how draft authors could handle the various ballotpositions.

Another important job of the IESG is to watch over the output of all the WGsto help prevent IETF protocols that are at odds with each other. This is whyADs are supposed to review the I-Ds coming out of Areas other than theirown, and each Area has adirectorate, a set of experienced volunteers whoreview I-Ds with a focus on potential issues for their area.

The quality of the IETF standards comes both from the review they get in theWorking Groups and the scrutiny that the WG review gets from the ADs.

2.2.3 Internet Architecture Board (IAB)

TheIAB is responsible for keeping an eye on the "big picture" of theInternet, and it focuses on long-range planning and coordination among thevarious areas of IETF activity. The IAB stays informed about importantlong-term issues in the Internet, and it brings these topics to the attentionof people it thinks should know about them.

IAB members pay special attention to emerging activities in the IETF. When anew IETF Working Group is proposed, the IAB reviews its charter forarchitectural consistency and integrity. Even before the group is chartered,the IAB members are more than willing to discuss new ideas with the peopleproposing them.

The IAB also sponsors and organizes theInternet Research Task Force (IRTF) andconvenes invitational workshops that provide in-depth reviews of specificInternet architectural issues. Typically, the workshop reports makerecommendations to the IETF community and to the IESG. The IAB keeps thecommunity informed through blog posts and by publishing RFCs.

The IAB also:

  • Approves NomCom's IESG nominations

  • Acts as the appeals board for appeals against IESG actions

  • Oversees the RFC series policy and procedures

  • Acts as an advisory body to ISOC

  • Oversees IETF liaisons with other standards bodies

Like the IESG, the IAB members are selected for two-year positions by theNomCom and are approved by the ISOC Board of Trustees.

2.2.4 Internet Assigned Numbers Authority (IANA)

The core registrar for the IETF's activities is theIANA. Many Internet protocols require that someone keep track of protocol items that were added after the protocol cameout. Typical examples of the kinds of registries needed are for TCP portnumbers and MIME types. IANA's work on behalf of the IETF is overseen by the IAB. There is ajoint group that advises IANA. IANA is funded byICANN.

Even though being a registry may not sound interesting, many IETFparticipants will testify to how important IANA has been for the Internet.Having a stable, long-term repository run by careful and conservativeoperators makes it much easier for people to experiment without worryingabout messing things up.

2.2.5 RFC Editor and RFC Production Center (RPC)

The RPC edits, formats, and publishes RFC's. This used to be done by oneperson, which is why you will still see the termRFC Editor; IETFers arefond of their history. Also, if you are a document author, you will mostcommonly come in contact with people responsible for editing your draft.Another important role is to provideone definitive repository for all RFCs.

A common misconception is that all RFCs are the work of the IETF. In fact,there are four sources of RFCs: the IETF, the IAB, the IRTF, and Independentstreams. It is likely that there will soon be a fifth source, which will be fordocuments on the RFC series itself. Only documents coming directly from theIETF through Working Groups, or sponsored by ADs, can have IETF consensusand be described as IETF specifications or standards.

Once an RFC is published, it is never revised. If the specification itdescribes changes, the standard will be re-published in another RFC that"obsoletes" the first. If a technical or editorial error is found in an RFC,an errata may be filed for review. If accepted, the errata will be linked tothe RFC and may be held for the next document update.

At the time of this writing, the model for the RFC Editor and the RPC isbeing revised under anIAB Program.In this revision, there is a position hired by the IETF LLC known as the RFCSeries Editor, who is advised by a couple of groups. As a newcomer, andpotential author, the details shouldn't matter much to you right now.

The RPC is contracted by the IETF LLC.

2.2.6 IETF Secretariat

There are a few people who are paid to support the IETF. The IETFSecretariat provides day-to-day logistical support, which mainly meanscoordinating face-to-face meetings and running the IETF presence onthe web, including theIETF web site,mailing lists, the repository for Internet-Drafts, and so on.The Secretariat also provides administrative assistance to the IESGand others.

The Secretariat is contracted by the IETF LLC.

2.2.7 IETF Trust

TheIETF Trust was set up to hold andlicense the intellectual property of the IETF, such as trademarks (the IETFlogo, etc.) and copyrights. The trust is a stable, legally-identifiableentity. Most participants never interact with the IETF Trust, beyond seeingit mentioned in RFC boilerplate. This is a good sign, and indicates thatthey are quietly doing their job.

2.3 IETF Mailing Lists

The IETF does most of its communication, and all of its official work,via email.

Anyone who plans to participate in the IETF should join theIETF announcement mailing list. This is where all of the meeting information, RFCannouncements, and IESG Protocol Actions and Last Calls are posted. Thislist is strongly moderated, and only the Secretariat and a small number ofIETF leaders can approve messages sent to the announcement list, althoughthose messages can come from a variety of people.

There is also ageneraldiscussion list that is unmoderated. This means that everyone canexpress their opinions about issues affecting the Internet. As an opendiscussion forum, it sometimes spins out of control and it helps to be quickon theDELETE MESSAGE button while also being slow to take offense.The mailing list does have acharter, however, whichpoints out that it is not a place for companies or individuals to solicit oradvertise. As of this writing, the charter is being revised. It is lightlymoderated by two people appointed by the IETF Chair; they used to be called theSargent At Arms (SAA), and you might see that term sometimes. There is alsoa process for banning persistent offenders from the list, but fortunatelythis is extremely rare.

There are also subset lists. Thei-d-announcelist only posts when a new Internet-Draft is submitted.It is moderated.Thelast-calllist is not moderated, and is for discussion of IETF Last Calls (thestage when the IETF community is given one last chance to comment on adraft before it is published as an RFC).

Every Working Group has its own mailing list.

Every IETF mailing list is archived. (Unfortunately, the archives forsome lists from many years ago, when the IETF did not have its ownservers, have been lost.)

Even though the IETF mailing lists "represent" the IETF participants atlarge, it is important to note that attending an IETF meeting does not meanyou'll be automatically added to any list; you'll have to "opt in"directly.

3 IETF Meetings

The computer industry is rife with conferences, seminars, expositions, andall manner of other kinds of meetings. IETF face-to-face meetings are notlike these. The meetings, held three times a year, are week-long gatheringswith the primary goals of helping Working Groups get their tasks done, andpromoting a fair amount of mixing among the WGs and the Areas. IETF meetingsare of little interest to sales and marketing folks, but of high interest toengineers and developers.

For many people, IETF meetings are a breath of fresh air when compared to thestandard computer industry conferences. There is no exposition hall, fewtutorials, and no big-name industry pundits. Instead, there is lots of work,as well as a fair amount of time for socializing for many participants.The IETF believes that having a drink together (often beer in the hotellobby, but drink whatever you want) is highly conducive to collaboration.

On the other hand, IETFers can sometimes be surprisingly direct, sometimesverging on rude. To build a climate in which people of many differentbackgrounds are treated with dignity, decency, and respect, the IETF has ananti-harassment policy, acode of conduct, and anOmbudsteam that you can reach out to.

The general flow of an IETF meeting is that it begins with anIETF Hackathon onSaturday and Sunday, tutorials and an informal gathering on Sunday, andWG and BoF meetings Monday through Friday. WG meetings last forbetween one and 2.5 hours each, and some WGs meet more than once,depending on how much work they anticipate doing. The WG chairs set theagenda for their meeting time(s).

There is a plenary session during the week, sometimes two. Either the firstpart, or a separate Technical Plenary, will have one or more technicalpresentations on topics of interest to many Working Groups. This isorganized by the IAB. The Administrative Plenary is organized by the IETFChair, and will have greetings from the meeting sponsor, reports on meetingattendance and IETF finances, and progress reports from most groups mentionedin the "Hierarchy" section above. This ends with an "open mic" session, withthe various groups on stage. This is a good time to share administrativeconcerns; praise is welcome, but more often concerns and gripes are raised.

There have been more than 110 IETF meetings so far.The list of future meetings is availableonline, and theyare also announced on theietf-announce mailing list mentioned above.

Note that COVID-19 disrupted the in-person meetings.After several virtual or online meetings, the IETF tried itsfirst hybrid meeting, in Vienna, in March 2022.

3.1 Registration

To attend an IETF meeting, either online or in person, you have to registerand pay a registration fee. If you cannot afford the online registration fee, youcan apply for a fee waiver during the registration process. The meeting site(if the meeting is not purely online) is generally announced at severalmonths ahead of the meeting -- earlier if possible. An announcement goes outvia email to theietf-announce mailing list, and information is posted onthe IETF web site, that same day.Upcoming meeting locations are also mentioned at the plenary, and the hostfor the next meeting often gives a welcome.

You can register online at the IETF website, or in person throughout theweek. There are different fee schedules for early-bird, latecomers,single-day, and so on. The general registration fee covers all of the week'smeetings, the Sunday eveningWelcome Reception, and afternoon beverage andsnack breaks.

The IETF and related organizations are committed to transparency and protectingthe privacy of individuals. For information about the personal datathat is collected, and how it is managed, please see theprivacy statement.

You might also consider subscribing to the meeting-specific email list, whichis presented as an option when you register to participate in the meetingeither in-person or remotely. Discussions on the meetings list can be highvolume and fairly wide-ranging about meeting-specific issues, but it is alsoa channel for sharing information that many find useful to understand what isgoing on during the meeting itself. Topics often include information aboutlocal mass transit, interesting sites to see, desire to buy or sell asocial event ticket, and so on. Local experts, people who live in the area,often respond to questions and can be very helpful.

Sunday is an excellent day to join the meeting, unless you already came onSaturday for the hackathon. Sunday is the day for the newcomer's tutorial, aswell the Quick Connections session where newcomers get to meet withexperienced IETF participants. After these sessions there is the welcomereception, a popular event where you can get a small bite to eat andsocialize with other attendees.

During registration, you will be asked to confirm that you agree tofollow theNote Well. You can also read it, anytime,online.This points out the rules for IETF intellectual property rights (IPR),anti-harassment, and other important guiding policies for the IETF.These slides will also be shown before every WG session; as it getslater in the week, the slide transitions tend to get faster and faster.

If you need to leave messages for other attendees, you can do so at the corkboards that are usually near the IETF registration desk. These cork boardswill also have last-minute meeting changes and room changes. The agenda isavailable online, and changes can happen up to the last minute, such ascancelling a WG meeting.

You can also turn in lost-and-found items to the registration desk. At theend of the meeting, anything left over from the lost-and-found will usuallybe turned over to the hotel or brought back to the Secretariat's office.Incidentally, the IETF registration desk is often a convenient place toarrange to meet people. If someone says "meet me at registration," you shouldclarify if they mean the IETF registration desk, or the hotel registrationdesk: This has been a common cause of missed connections.

3.2 Take the Plunge and Stay All Week!

IETF WG meetings are scheduled from Monday morning through Friday afternoon.Associated non-WG meetings often take place on the preceding or followingweekends, and unofficial "side meetings" can also be scheduled during theweek. It is best to plan to be present the whole week, to benefit fromcross-fertilization between WGs and from hallway discussions (both offline aswell as in online environments such as thegather.town website). As notedbelow, the agenda is fluid, and there have been instances of participantsmissing important sessions due to last-minute scheduling changes after theirtravel plans were fixed. Being present the whole week is the only way toavoid this annoyance.

If you cannot find meetings all week to interest you, you can still make themost of the IETF meeting by working between sessions. Almost every attendeehas a laptop, and it is common to see many of them in the terminal room or inthe lobbies and hallways working during meeting sessions. The IETF sets up a high-speed network throughout the hotel for the duration of the meeting,and there's no charge to use the "IETF wifi." This usually covers many placesof the meeting venue (restaurants, coffee shops, and so on), so catching upon email when not in meetings is a fairly common task for IETFers.

Note that many people use their laptops actively during meeting sessionsfor practical purposes such as consulting drafts. Power strips in all meetingrooms and hotel rooms will provide only the sockets permitted by localregulations, so ensure in advance that you have an appropriate travel adapter.

3.3 Newcomer Training

Newcomers should attend the Newcomer's Tutorial on Sunday, which isespecially designed for them. The tutorial is organized and conducted by theIETF Education, Mentoring, and Outreach Directorate (EMODIR) team and isintended to provide useful introductory information. The session covers thestructure of the IETF, how to get the most out of the meeting, and many otheressential and enlightening topics for new IETFers. The IETF has aYouTube channel which has the previous tutorials. This has recently been broken down intofour 15-minute segments which might be easier to view.

Quick Connections is a session limited to newcomers and experienced IETFparticipants. It is a great chance to meet people, and establish contactsthat can be useful during the rest of the week. Registration is requiredas space is limited. It is held right before the welcome reception.

3.4 Dress Code

At meetings people generally dress informally, and newcomers could feel outof place if they show up Monday morning in suits. The general rule is "dressfor casual comfort." Note that the hotel air conditioning might mean bringinga sweater or other covering as well.

3.5 Working Group Meetings

The heart of an IETF meeting is the WG meetings themselves. Different WGschairs have very different styles, so it is impossible to generalize how a WGmeeting will feel. All WGs have agendas, however, and most will follow thefollowing approach.

At the beginning of the meeting, the chair will pass around thebluesheets, which are paper forms on which everyone writes their name and theiraffiliation. These are archived and used for planning capacity needs for thenext time the WG meets. In very rare cases, they have been used to indicateexactly who showed up. When you are handed the sheet, sign your name andpass it along in the same direction. If you arrive after the start, at theend of the meeting you can go up front and sign it then. For virtualattendance using theMeetEcho video conference system, attendance ishandled by accessing the application.

After the blue sheets, there are calls for volunteers to take minutes. Morethan one person can do so, and they are often done on a Web page using acollaborative editing app. Taking minutes can be a good way to ensure youfollow the discussions without distraction! The link to the web page will bepart of the WG entry that is part of the online meeting agenda. There isalso a chance to make any last-minute updates to the agenda. This is knownas "agenda bashing." Finally, there will be a review of the Note Well. Theorder in which these things happen can vary, but they are all done before themeeting really "starts."

To speak during a meeting, go to the microphone(s) located near the middle ofthe room. For controversial topics, there will be a line at the mic, but donot hesitate to be the first person at the line if you have a question or acontribution to the discussion. The WG chair or presenter will indicate whenyou can speak. Although it would be easier to just raise your hand from whereyou are sitting, the mics perform a very useful task: they let the peoplelistening remotely and in the room hear your question or comment. When youfirst speak, say your name and affiliation for identification purposes. Ifyou miss this, folks will often say "name!" to remind you. Don't beembarrassed if this happens, it's not uncommon.

3.6 Seeing Spots Before Your Eyes

Some attendees will have a little colored dot on their name tag, and a fewpeople have more than one. These dots identify people who have volunteered todo extra work, such as being a WG chair, an IESG member, and so on. Thecolors have the meanings shown here.

Table 3
ColorMeaning
BlueWorking Group/BOF Chair
GreenMeeting Host/Sponsor
RedIAB member
YellowIESG member
PinkIRSG member
OrangeNominating Committee member
BlackIETF LLC Board

Members of the press wear orange-tinted badges with the word "press" on them.

As newcomer, don't be afraid to strike up conversations with people who wearthese dots. If the IAB and IESG members and Working Group and BOF chairsdidn't want to talk to anybody, they wouldn't be wearing the dots in thefirst place! Note, however, that IETF meetings are usually intense times forArea Directors. Talking to an AD during an IETF meeting will often resultin them asking you to send email after the meeting ends.Also, when you starta hallway conversation with an Area Director (or even a WG chair, for thatmatter), it is often good to give them about 30 seconds of context for thediscussion.

Near the registration area there are usually ribbons and markers so thatpeople can label their specific interests, history, and so on.Many people use them to make (inside) jokes, which are sometimes amusing.

3.7 Terminal Room

The IETF wifi is provided by volunteers who run the Network Operations Center(NOC). The terminal room is where you can get wired connectivity and limitedaccess to a printer. The people and companies that donate their equipment,services, and time are to be heartily congratulated and thanked.

You must be wearing your badge in order to get into the terminal room. Theterminal room provides power strips, Ethernet ports, and wifi(for the people who don't need Ethernet but want power). What it doesn'tprovide are terminals; the name is historical. The help desk in the terminalroom is also a good place to ask questions about network failures, althoughthey might point you off to different networking staff.

3.8 Meals and Snacks

Although it is true that some people eat very well at the IETF, they find thefood on their own since lunches and dinners are not included in theregistration fee. In addition to socializing, dinner meetings can be a goodway to get additional work done.

If sponsorship for it is secured, the welcome reception provides drinksand appetizers but is not meant to be a full replacement for dinner.Sometimes a continental breakfast can be included with the hotel registration.There IETF meeting also includes a morning coffee and snack break, anda similar one in the afternoon.

If you prefer to get out of the hotel for meals, the local host usuallyprovides a list of places to eat within easy reach of the meeting site,and the meeting-specific email list is also a useful source.

3.9 Social Event

Another of the most important things organized and managed by the host is theIETF social event. The social event is sometimes high-tech-related event, orit might be in an art museum or a reception hall. Note, however, that not allIETF meetings have social events.

Newcomers to the IETF are encouraged to attend the social event. Wear yourname tag and leave your laptop behind. The social event is designed to givepeople a chance to meet on a social, rather than technical, level. Thesocial ticket costs extra, is reserved at registration time, and has limitedcapacity. People looking to buy or sell a social ticket often post to theemail list, or on the corkboards mentioned above.

3.10 Agenda

The agenda for the IETF meetings is a very fluid thing. It is available onthe web and through the IETF mobile apps starting a few weeks before themeeting. Of course, "final" in the IETF doesn't mean the same thing as itdoes elsewhere in the world. The final agenda is simply the last versionposted before the meeting. The Secretariat will post agenda changes on thebulletin board near the IETF registration desk (reminder, not the hotelregistration desk!). These late changes are not capricious: they are made"just in time" as session chairs and speakers become aware of unanticipatedconflicts. The IETF is too dynamic for agendas to be tied down weeks inadvance.

A map showing the hotel layout and, specifically the meeting rooms, is alsoavailable with the agenda. Room assignments can change as the agendachanges. Some Working Groups meet multiple times during a meeting, and everyattempt is made to have a Working Group meet in the same room for eachsession.

3.11 EMODIR to the Rescue

If, after you finish reading this document, certain aspects of the IETF stillmystify you, you'll want to drop in on the on-site training offered by theEducation, Mentoring, and Outreach (EMODIR) team. In addition to theNewcomer training mentioned above, EMODIR also hosts informal newcomergatherings during the coffee break sessions. Details vary for each meeting,so watch the agenda and the newcomer-specific email list.

EMODIR also organized in-depth technical tutorials, useful for newcomersand experienced IETFers alike.These are also announced as part of the program, and are usually onSundays.

Finally, EMODIR runs theIETF Guides program, pairing newcomers with anexperienced IETF person to help you become acclimated and effective quickly.This has not worked out very well during the all-virtual meetings, frankly.If you are interested, watch for the announcement. Ideally you have a callwith your mentor before the meeting, a meeting during the beginning of themeeting, and check in some time during the meeting, so they can help you withany questions you might have.

Details on EMODIR membership and charter are availableonline.

3.12 Where Do I Fit In?

The IETF is different things to different people. There are many people whohave been very active in the IETF who have never attended an IETF meeting,and you should not feel obligated to come to an IETF meeting just to get a feelfor the IETF.If, however, you decide to come, this document andRFC 4144: How to Gain Prominence and Influence in Standards Organizationsprovides some pointerson how to make your meeting a success.The following guidelines (based on stereotypes of people in variousindustries) might help you decide whether you actually want to come and, ifso, what might be the best use of your time at your first meeting.

3.12.1 IT Managers

As discussed throughout this document, an IETF meeting is nothing like anytrade show you have attended. IETF meetings are singularly bad places to goif your intention is to find out what will be hot in the Internet industrynext year. You can safely assume that going to Working Group meetings willconfuse you more than it will help you understand what is happening, or willbe happening, in the industry.

This is not to say that no one from the industry should go to IETF meetings.As an IT manager, you might want to consider sending specific people who areresponsible for technologies that are under development in the IETF. As thesepeople read the current Internet-Drafts and email traffic on the relevantWorking Group lists, they will get a sense of whether or not their presencewould be worthwhile for your company or for the Working Groups.

3.12.2 Network Operators and ISPs

Knowledge of how networks are run is indispensable for the developmentof new (versions of) protocols. Especially if you work for the type ofnetwork that is always using the very latest hardware and software,and you are already following the relevant Working Groups,you could certainly find participating in the IETF valuable.Note that the IETF has several WGs focused on operations, that mightbe particularly relevant.

Finally, note that the IETF is increasingly focused on encrypting networktraffic, and that this has implications for operators. A fair amount of IETFwork also covers many other parts of operations of ISPs and largeenterprises, and the input of operators from each of these types oforganizations is quite valuable to keep this work vibrant and relevant. Manyof the best operations documents from the IETF come from real-worldoperators, not vendors and academics.

3.12.3 Networking Hardware and Software Vendors

The image of the IETF being mostly network researchers may have been true inthe distant past, but the jobs of today's attendees are typically inindustry. In most areas of the IETF, employees of vendors are the oneswriting the protocols and leading the Working Groups, so it's completelyappropriate for vendors to attend. If you create Internet hardware orsoftware, or run a service available on the Internet, and no one from yourcompany has ever attended an IETF meeting, it behooves you to come to ameeting if for no other reason than to tell the others how relevant themeeting was or was not to your business.

This is not to say that companies should close up shop during IETF meetingweeks so everyone can go to the meeting. Marketing folks, even technicalmarketing folks or pre-sales, are safe in staying away from the IETF as long assome of the technical people from the company are at the meeting. Similarly,it isn't required, or likely useful, for everyone from a technical departmentto go, especially if they are not all reading the Internet-Drafts andfollowing the Working Group mailing lists. Many companies have just a fewdesignated meeting attendees who are chosen for their ability to do completeand useful trip reports. In addition, many companies have internalcoordination efforts and a standards strategy. If a company depends on theInternet for some or all of its business, the strategy should probably coverthe IETF, but note that IETF participation is as anindividual not aformal representative of their employer.

3.12.4 Academics

IETF meetings are often excellent places for all kinds of researchers to findout what is happening in the way of soon-to-be-deployed protocols, andnetworking architecture and infrastructure. Professors and grad students (andsometimes overachieving undergrads) who are doing research in networking orcommunications can get a wealth of information by following Working Groups intheir specific fields of interest. Wandering into different Working Groupmeetings can have the same effect as going to symposia and seminars in yourdepartment. Researchers are also, of course, likely to be interested in IRTFactivities.

In addition, the IRTF and ACM co-host the annualApplied Networking Research Workshop,normally scheduled during the July IETF meeting Registration is required,IETF attendees can attend for free. The IRTF also hosts theApplied Networking Research Prize,which includes a cash prize, a travel grant to attend, and a chance topresent. See the web page for requirements.

3.12.5 Computer Trade Press

If you're a member of the press and are considering attending IETF,please see thespecial section below.

3.13 Proceedings

IETF proceedings are compiled in the weeks and months after each meeting andare availableonline.Be sure to look through a copy at least once; the proceedings are filled withinformation about IETF that you're not likely to find anywhere else. Forexample, you'll copies of every session's slides, links to the videorecording, copies of the blue sheets (attendance), and so on.

3.14 Other General Things

IETFers in general are very approachable. Never be afraid to approach someoneand introduce yourself. Also, don't be afraid to ask questions, especiallywhen it comes to jargon and acronyms. If someone is presenting an updateto their draft, feel free to step up to the mic and ask a clarifyingquestion. Before you do, however, make sure to have read the draft first.Working Group meetings are not a time for general tutorials.

Hallway conversations are very important. A lot of very good work gets doneby people who talk together between meetings and over lunches and dinners.Every minute of the IETF can be considered work time (much to some people'sdismay).

A side meeting (historically but often inaccurately called a "bar BOF") is anunofficial get-together between WG meetings or in the late evening, duringwhich a lot of work gets done. These side meetings spring up in manydifferent places around an IETF meeting, such as restaurants, coffee shops,unused hall spaces and the like. You can read more aboutBirds-of-a Feather sessions (BOFs)in section 5.

The IETF meetings, and the plenary session in particular, are not places forvendors to try to sell their wares. People can certainly answer questionsabout their company and its products, but bear in mind that the IETF is not atrade show.

There is always a "materials distribution table" near the registration desk.This desk is used to make appropriate information available to the attendees(e.g., copies of something discussed in a Working Group session, descriptionsof online IETF-related information). Please check with the Secretariat beforeplacing materials on the desk; the Secretariat has the right to removematerial that they feel is not appropriate.

3.15 Remote Participation

People have joined IETF meetings remotely for a long time, but the tools forthis have changed a lot over the years. Currently the IETF uses a browser-based tool known asMeetEcho. There is also a text-based discussionforum calledJabber. This is integrated into MeetEcho, but there are alsostand-alone clients available. Planned for 2022, theZulip textwill be available. Each WG will have its own stream.

The links for the Meetecho rooms, the Jabber chats, and meeting materials,can always be found in the right-hand side of the agenda, under the differenticons. All sessions are recorded and can be viewed after the meeting, alongwith chat logs and meeting minutes. This can be useful to refresh yourmemory while writing a trip report, or for catching up on what happenedwhen you wanted to be in two WG meetings at once. It happens; schedulingconflicts are unavoidable.

4 Working Groups

The vast majority of the IETF's work is done in its many Working Groups; atthe time of this writing, there are well over one hundred different WGs.BCP 25, "IETF WorkingGroup Guidelines and Procedures," is an excellent resource for anyoneparticipating in WG discussions. The full list of working groups can befound on thedatatracker.

A WG is really just a mailing list with a bit of supervision and facilitation.You "join" the WG by subscribing to the mailing list; all mailing lists are opento anyone. Anyone can post to a WG mailing list, although non-subscribers haveto have their postings approved first.

More importantly, each WG has a charter that the WG is supposed to follow. Thecharter states the scope of discussion for the Working Group and its goals. TheWG's mailing list and face-to-face meetings are supposed to focus on only what isin the charter and not to wander off on other "interesting" topics. Of course,looking a bit outside the scope of the WG is occasionally useful, but the largemajority of the discussion should be on the topics listed in the charter. In fact,some WG charters actually specify what the WG will not do, particularly if therewere some attractive but nebulous topics brought up during the drafting of thecharter. The list of all WG charters makes interesting reading for folks who wantto know what the different Working Groups are supposed to be doing. Each WG hasits own page on the datatracker.

4.1 Working Group Chairs

Each Working Group has one or two (or, rarely, three) chairs. The role of theWG chairs is described in bothBCP 11andBCP 25.

Chairs have responsibility for the technical and non-technical qualityof WG output. The chair must keep the WG productive, and making progresson its drafts. Sometimes there is a WG Secretary to help. Document editors,too, are usually incentivized to make progress on their drafts. The chairmust manage WG discussion, both on the list and by scheduling meetingswhen appropriate. Sometimes discussions get stuck on contentious pointsand the chair may need to steer people toward productive interaction andthen declare when rough consensus has been met and the discussion isover. Sometimes chairs also manage interactions with non-WG participantsor the IESG, especially when a WG document approaches publication. Asyou can imagine given the mix of secretarial, interpersonal, andtechnical demands, some Working Group chairs are much better attheir jobs than others.

4.2 Getting Things Done in a Working Group

One fact that confuses many newcomers is that the face-to-face WG meetings are muchless important in the IETF than they are in most other organizations. Any decisionmade at a face-to-face meeting must also gain consensus on the WG mailing list. Thisis sometimes phrased as "at the last WG meeting, we decided XXX; if you disagreeplease speak up by the end of the week" and you'll therefore often hear the phrase"to be confirmed on the list." There are numerous examples of important decisionsmade in WG meetings that are later overturned on the mailing list, often becausesomeone who couldn't attend the meeting pointed out a serious flaw in the logicused to come to the decision. Finally, WG meetings aren't "drafting sessions"as they are in some other standards bodies: in the IETF, drafting is done elsewhere.

Another aspect of Working Groups that confounds many people is the fact thatthere is no formal voting. The general rule on disputed topics is that theWorking Group has to come to "rough consensus," meaning that a very largemajority of those who care must agree, and that those in the minority have had achance to explain why. Generally consensus is determined byhumming: if youagree with a proposal, you hum when prompted by the chair. Most hum questionscome in three parts: you hum to the first part if you agree with the proposal,to the second part if you disagree, or to the third part if you do not haveenough information to make up your mind. Newcomers find it quite peculiar, butit works. It is up to the chair to decide when the Working Group has reachedrough consensus; sometimes the responsible AD will also do so.

The lack of formal voting has caused some very long delays for some proposals,but most IETF participants who have witnessed rough consensus after acrimoniousdebates feel that the delays often result in better protocols. (And, if youthink about it, how could you have "voting" in a group that invites allinterested individuals to participate, and when it's impossible to count theparticipants?) A common definition and practice of humming can be found inRFC 7282: On Consensus and Humming in the IETF.

A related problem is that some people think that their topic should be discussedin the WG even when the WG chair believes it is outside the scope of the charter.If the WG agrees, they can work tore-charter so that the topic is in scope.The individual can also bring their concerns to the responsible AD.

When a WG has fulfilled its charter, it is supposed to cease operations. (MostWG mailing lists continue on after a WG is closed, still discussing the sametopics as the Working Group did.) In the IETF, it is a mark of success that theWG closes up because it fulfilled its charter. This is one of the aspects of theIETF that newcomers who have experience with other standards bodies have a hardtime understanding.

4.3 Working Group Documents

There is an official distinction between WG I-Ds and individual I-Ds. A WGwill have to review an individual draft before deciding if it should be adoptedby the WG. The WG chairs appoint who will be the authors or editors of theI-Ds; often those who wrote the initial draft continue work on behalf of theWG. Procedures for Internet-Drafts are covered in much more detail later in thisdocument.

For Working Group documents, the document editor serves at the pleasure of theWG Chair. There is often more than one editor for Working Group documents,particularly for complex documents. The document editor is responsible forensuring that the contents of the document accurately reflects Working Groupdecisions; when a document editor does not follow the WG consensus, the WGChairs will either be more forceful about getting changes that match theconsensus or replace the document editor with someone more responsive to the WG.As a Working Group document is progressing, participants suggest changes on theWorking Group's mail list (or online if the document is maintained somewhereaccessible); the editors are expected to follow the discussion and make changeswhen there is consensus.

Sometimes a Working Group will consider several alternatives before selecting aparticular Internet-Draft as a Working Group document. A Working Group willoften take ideas from several of the alternatives to create a single WorkingGroup document; in such a case, the chair determines who will be listed asauthors on the title page and who will be acknowledged as contributors in thebody of the document.

When a WG document is ready to progress beyond the WG, the WG Chairs will assigna "shepherd" to take over the final process. The role of the document shepherdis described inRFC 4858: Document Shepherding from Working Group Last Call to Publication. The chair, who knows the history of the draft within the WG, often does the shepherdwrite-up.

4.4 Preparing for Working Group Meetings

The most important thing thateveryone should do before coming to aface-to-face meeting is to read the Internet-Drafts and RFCs ahead of time. WGmeetings are explicitly not for education: they are for developing the group'sdocuments and often the document is presented as a set of slides saying"here's what changed since last meeting." Even if you do not plan to sayanything in the meeting, you should read, or at least skim, the group'sdocuments before attending so you can understand what is being said.

It's up to the WG chairs to set the meeting agenda, usually a few weeks inadvance. If you want something discussed at the meeting, be sure to let thechair know about it. The agendas for all the WG meetings are available inadvance on the datatracker, and links to will be found on every full meetingagenda. Unfortunately, some WG chairs are lax (if not totally negligent) aboutturning them in.

The Secretariat only makes the full IETF meeting schedule a few weeks inadvance, and the schedule often changes as little as a week before the firstday. If you are only coming for one WG meeting, you may have a hard time bookingyour flight with such little notice, particularly if the Working Group's meetingchanges schedule. Be sure to keep track of the current agenda so you canschedule flights and hotels. But, when it comes down to it, you probablyshouldn't be coming for just one WG meeting. It's likely that your knowledgecould be valuable in a few WGs, assuming that you've read the I-Ds and RFCsfor those groups. Work in the IETF is often reciprocal, contribute positively toothers work and you are more likely to receive comments and feedback on yourwork.

If you are on the agenda at a face-to-face meeting, you should prepare a fewslides and mail them to the chair before the meeting. Don't come with atutorial; people are supposed to read the I-Ds in advance. Projectors forlaptop-based presentations are available in all the meeting rooms.

And here's a tip for your slides: don't put your company's logo on every one,even though that is a common practice outside the IETF. The IETF frowns on thiskind of corporate advertising (except for the meeting sponsor in the plenarypresentation), and most presenters don't even put their logo on their openingslide. The IETF is about technical content, not company boosterism. Slides areoften plain black and white for legibility, with color used only when it reallyadds clarity. Again, the content is the most important part of the slides, nothow it's presented.

One thing you might find helpful, and possibly even entertaining, during WorkingGroup sessions is to follow the running commentary on the Jabber room associatedwith that Working Group. Jabber is a free, streaming XML technology mainly usedfor instant messaging. You can find pointers to Jabber clients for manyplatforms at (https://xmpp.org/xmpp-software/clients). The Jabber chatrooms havethe name of the Working Group followed by "@jabber.ietf.org". Those rooms are,in fact, available year-round, not just during IETF meetings, and some are usedby active Working Group participants during protocol development.

4.5 Working Group Mailing Lists

As we mentioned earlier, the IETF announcement and discussion mailing lists arethe central mailing lists for IETF activities. However, there are many othermailing lists related to IETF work. For example, every Working Group has its owndiscussion list. In addition, there are some long-term technical debates thathave been moved off of the IETF list onto lists created specifically for thosetopics. It is highly recommended that you follow the discussions on the mailinglists of the Working Groups that you wish to attend. The more work that is doneon the mailing lists, the less work that will need to be done at the meeting,leaving time for cross pollination (i.e., attending Working Groups outside one'sprimary areas of interest in order to broaden one's perspective).

The mailing lists also provide a forum for those who wish to follow, orcontribute to, the Working Groups' efforts, but can't attend the IETF meetings.That's why IETF procedures require all decisions to be confirmed "on the list"and you will often hear a WG chair say, "Let's take it to the list" to close adiscussion.

Every WG has a dedicated page on the datatracker site, and the "About" tab willpoint to mailing list subscription and archives.

4.6 Interim Working Group Meetings

Working Groups sometimes hold interim meetings between IETFs. Interim meetingsaren't a substitute for IETF meetings, however -- a group can't decide to skip ameeting in a location they're not fond of and meet in Cancun (or even someplacemundane) three weeks later, for example. Interim meetings need to be announcedat least one month in advance. Location and timing need to allow fair access forall participants. Like regular IETF meetings, someone needs to take notes andthe group needs to take attendance. Decisions tentatively made during an interimWG meeting must still be confirmed on the mailing list. Interim meetings aresubject to the IETF Note Well. Most interim meetings are virtual these days and have the same reporting requirements as face-to-face virtual meetings.

The IESG has rules for advance notice on time and place of interim Working Groupmeetings, as well as reporting the results of the meetings. The purpose of theserules is to make interim meetings accessible to as many Working Group members aspossible and to maintain the transparency of the Working Group process.

5 BOFs and Dispatching

In order to form a Working Group, you need a charter and someone who is ableto be chair. In order to get those things, you need to get people interestedso that they can help focus the charter and convince an Area Director thatthe project is worthwhile. A face-to-face meeting is useful for this. Infact, very few WGs get started without an initial meeting.

ABirds of a Feather (BOF) meeting has to be approved by the Area Directorin the relevant area, in consultation with the IESG and the IAB, before itcan be scheduled. If you think you need a new WG, approach an AD with yourproposal and see what they think. You will have to write some informativebackground text, and they will work with you to get it scheduled. Of course,you can also gather interested people and work on a draft charter in themeantime.

BOF meetings have a very different tone than do WG meetings. The purpose ofa BOF is to make sure that a good charter with good milestones can becreated, that there are enough people willing to do the work needed in orderto create standards, and that any standards would get adoption. Often aself-selected group of key people will get together after the BOF torefine the draft charter.

Generally, there are only two BOF meetings allowed for the same topic.Sometimes it is obvious after one meeting that a WG should be created, andsometimes it is obvious a WG would not be successful.

If you have a draft already written, you can submit it to the relevant"dispatch" WG. Each area has one of these. Their job is to review submitteddocuments, and come to a decision about the next steps: possibilities includecreate a new WG, send to an existing WG, hold a BOF, and so on.

An advantage of using the dispatch WG compared to a BOF is that thediscussion is more limited and focused. On the other hand, a draft mighttend to limit what the other folks in the BOF want to do in the charter.Remember that most BOFs are held in order to get support for an eventualWorking Group, not to get support for a particular document.

6 RFCs and Internet-Drafts

This section discusses Internet-Drafts and RFCs in the IETF stream, that is,it describes how documents are produced and advanced within the IETF. For abrief note on other RFC streams, see above.

If you're a new IETF participant and are looking for a particular RFC orInternet-Draft, you can use the IETFDatatracker. This website,https://datatracker.ietf.org/,has a text search capability (including content, keywords, author, and soon), and the search results point to the document status, page count, andother useful information. A little-known hint is thatdt.ietf.org is anabbreviation (a DNS CNAME entry) for the longer "datatracker.ietf.org"hostname.

Most RFCs in the IETF stream follow the same process, and the sectionsbelow discuss the process and some of the issues. Note that there areother ways to get an RFC published, particularly if it is not intendedfor the standards track. For the sake of brevity, we will not mentionthose here. After all, this document is about "the Way of the IETF"and the main Way is "developing standards."

If you are interested in learning more about how to author an Internet-Draftyourself, theI-D Authors websitehas a lot of information and resources, including pointers to online toolsthat can help.

6.1 The Overall Process

The very first step is to have a draft document. Internet-Draftsshould follow a specific format, and are required to have particularsections. This will be discussed morebelow.

RFCs are generally written by a Working Group. If an appropriateWG doesn't seem to exist, then theBOF or Dispatchprocess mentioned above can be used to learn which one is appropriate,or start the process to create one.

Once a potential WG exists, the document must beadopted. To do this, yousubmit your individual draft to the datatracker. It should start withdraft-YOURNAME-brief-subject whereYOURNAME is your name. Send a note tothe WG mailing list, with an introduction to the draft, and why you think itis appropriate. After any discussion, the WG Chair will issue acall foradoption. If consensus is to adopt the draft, you will be asked to submitit with the namedraft-ietf-WGNAME-brief-subject; you can probably guesswhatWGNAME should be.

Note that as part of submitting an Internet Draft according to the rules, yougrant the IETF certain rights. These rights give the IETF the ability toreliably build upon the work you have brought forward. These rights are heldby the IETF Trust.BCP 78explains the certain rights the IETF Trust takes on for submissions.

Once a WG adopt a document, the WG as a whole has the right of "changecontrol." This means the WG, can make any changes to the document, the oneyou initially wrote, that they want. If you are not comfortable with this,then the IETF is not the place for your document. There are a few moredetails on this below.

The WG now "works on" the document. This will be a combination ofmailing list discussion, perhaps agenda time at a meeting, and publishingupdated drafts. (Every draft ends with-NN where the digits indicatethe draft number.)

At some point, the document will seem finished. The WG Chair will put thedocument inWG Last Call (WGLC) which gives the members of the WG a chancefor last-minute changes. It can be frustrating to get a bunch of changesafter you think you're done, but don't take it personally. Like many things,people are often deadline-driven.

After WGLC, the responsible AD (the one who oversees the WG) does a review.They will probably have comments that must be resolved by you and the WG;it's quite likely you'll have to publish a new draft. Then the IESG andthe overall IETF reviews the draft, as mentioned above.The purpose of IETF Last Call is to get community-wide discussion ondocuments before the IESG considers them. Note the worddiscussion here. Itis generally considered bad form to send IETF Last Call comments on documentsthat you have not read, or to send comments but not be prepared to discussyour views. The IETF Last Call is not a vote. Having said that, IETF LastCall comments that come from people who have just read the document for thefirst time can expose issues that IETF and WG regulars may have completelymissed, which is why the discussion is open to everyone.

Finally, the draft is given to the RFC Production Center (RPC), and preparedfor publication. There might be other changes required, including reviews byIANA for registrations and the like. The most common item you'll hear aboutthis isAUTH48 state, which means the document is in the final stages ofcopy-editing by the RPC and you. The publication process can take weeks,but be patient, and you'll eventually see an email announcement sayingthat your brand-new RFC has been published. Congratulations!

A much more complete explanation of these steps is contained inBCP 9.This set of documents goes into great detail on a topic that isvery often misunderstood, even by seasoned IETF participants: different typesof RFCs go through different processes and have different rankings.

6.2 Common Issues

There are two major issues that often come up while preparing I-Ds:copyright and patents.

We discussed copyright above, but expand on it here. When the IETF adopts anInternet-Draft, it is required that theboilerplate, the common text thatappears in every draft, has a notice that says the IETF,and the documentauthors own the copyright. This means that while the IETF can do what itwants with the document, within limitations so can you. You cannot, forexample, claim this is an IETF standard, nor use the IETF trademarks.

Incidentally, the change control on Internet standards doesn't end when theRFC is published. Things can be changed later for a number of reasons, suchas to solve a newly-discovered problem or address new use-cases. These laterchanges are also under the control of the IETF, not the editors of thestandards document.

The second issue is patents. The goal of the IETF is to have its standardswidely used and validated by the marketplace. If creating a product thatuses a standard requires getting a license for a patent, people are lesslikely to implement the standard. Not surprisingly, then, the general rulehas been "use good non-patented technology where possible."

Of course, this isn't always possible. Sometimes patents appear after astandard has been established and there is little the IETF can do about that.Sometimes there's a patent on something that is so valuable that there isn'ta non-patented equivalent, and generally the IETF tries to avoid it.

Sometimes the patent holder is generous and promises to give all implementorsof a standard a royalty-free license to the patent, thereby making it almostas easy to implement as it would have been if no patent existed. Ideally,and this is the common case when a patent-holder is active in a document,the patent holder will grant free use of the patent to implement thespecification.

The official rules for all intellectual property rights (IPR) inIETF documents, not just patents but also code samples and the like,are covered inBCP 78 andBCP 79.

If you are writing an Internet-Draft and you know of a patent that applies tothe technology you're writing about, don't list the patent in the document.Instead, consult theIPR disclosures page. If you still have issues, consult with the WG Chair orthe responsible AD. Intellectual property rights aren't mentioned in RFCsbecause RFCs never change after they are published, while knowledge of IPRcan change at any time. Therefore, an IPR list in an RFC could be incompleteand mislead the reader.BCP 79 provides specific text that should be added to RFCs where the authorknows of IPR issues.

6.3 Writing an Internet-Draft

Every RFC starts its life as an I-D. Internet-Drafts have the same format as an RFC,and are required to have all the content that should appear in the RFC. Thisincludes a couple of sections detailed below. A draft may also have moreinformation, such as an incremental list of changes from previous versions ofthe draft, or pointers to online locations for raising issues and suggestingchanges.

For the past several years, the official canonical source of RFCs asRFC 7991: The "xml2rfc" Version 3 Vocabulary. Some people enjoy writing in XML, and some don't.An alternative for the second group is to use a specific dialect of markdown,which is then converted to XML as needed (and especially during thepublication process). A recent trend is the increasing use of markdown, andhosting I-Ds on GitHub to attract a wider audience of Internet-savvy users.Some information on this can be found atRFC 8874: Working Group GitHub Usage Guidance.

The IETF is setting up a new site,https://authors.ietf.org,to contain guides and online tools to help both new and experienced authors.As of this writing, it's still a draft but it does contain a greatdeal of useful content. You should feel free to use the site, and offer feedback.

Outside of the formatting decision, the most important document you canread isGuidelines to Authors of Internet-Drafts.That document explains the naming conventions, formatting requirements,required content, and details of how to submit (also calledpost) yourdraft.

6.3.1 Internet-Draft Language

It is common for Internet-Drafts that revise existing RFCs to have draftnames with "bis" in them, meaning "again" or "twice." For example, a draftmight be called "draft-ietf-uta-rfc6125bis" meaning that this is intended tobe a revision of, and eventual replacement for, RFC6125.

Writing clear specifications can be a bit of an art, particularly for peoplewho don't have English as their native language. You can keep thespecification very short, with just a list of requirements, but that tends tocause implementors to take too much leeway. If you instead make thespecification very wordy with lots of suggestions, implementors tend to missthe requirements (and often disagree with your suggestions anyway). Anoptimal specification is somewhere in between.

One way to make it more likely that developers will create interoperableimplementations of standards is to be clear about what's being mandated in aspecification. Over time, the IETF has realized that defining a few wordswith specific meanings helps a great deal.BCP 14 defines about a dozen keywords that can be used to clarify what arerequirements, as compared to what is purely informative.It defines the meaning of words likeMUST and points out that ithas to appear in all uppercase to its special meaning.

It is not uncommon for feedback on standards-track I-Ds to questionthe particular uses of what is called "2119 language." For example,"The document says MAY but doesn't explain why not; should it bea MUST?"

6.3.2 About References

One aspect of writing IETF standards that trips up many newcomers is the ruleabout how to makenormative references to non-IETF documents or to otherRFCs in a standard. A normative reference is a reference to a document thatmust be followed in order to implement the standard. A non-normativereference (sometimes called aninformative reference) is one that ishelpful to an implementor but not strictly needed to implement it.

An IETF standard may make a normative reference to any other standards-trackRFC that is at the same standards level or higher, or to any "open standard"that has been developed outside the IETF. The "same level or higher" rulemeans that before a standard can move from Proposed to Internet Standard, allof the RFCs that appear as a normative reference must also be an InternetStandard. This rule gives implementors assurance that everything in anInternet standard is quite stable, even the things referenced outside thestandard. This rule, and its exceptions, is described inBCP 97.

There is no hard-and-fast rule about what is an "open standard", butgenerally this means a stable standard that was made by agenerally-recognized SDO, and that anyone can get a copy of, although notnecessarily for free. If the external standard changes, you have toreference the particular instantiation of that standard in yourspecification, as with a designation of the date of the standard. Someexternal standards bodies don't make old standards available, which is aproblem for IETF standards that need to be used in the future. When in doubt,ask the WG chair or AD if a particular external standard can be used in anIETF standard.

6.3.3 About Required Content

Every draft is required to have some content. Some of this is boilerplatetext about copyright, "2119 keyword," and so on. The document formattingtools will generate this for you automatically if you use the right keyword.In addition, there are special sections that might be required for yourdraft, and you (and the WG) will have to write them.

Many IETF standards have extension points, such as unassigned fields ina message header, or for something like email or HTTP, an actual messageheader. Asmentioned above, IANA maintains onlineregistries for these. Because of the large and diverse kinds of registriesthat standards require, IANA needs to have specific information about how toregister parameters, what not to register, who (if anyone) approves anyregistration requests, and so on.

Anyone writing a draft that needs one or more registries, or adds values toexisting registries must have an "IANA Considerations" section. Authorsshould readBCP 26,"Guidelines for Writing an IANA Considerations Section in RFCs," whichdescribes how to properly ask for IANA to make the changes requested in theirdraft. If there are no considerations, it is a good idea to have the sectionand explicitly say "This document has no IANA requests."

Every draft must have a "Security Considerations" section. This describespossible threats or attacks, known vulnerabilities, information that could beexposed, and so on. It should also describe any strategies or mechanisms tomitigate them. When the security directorate (SECDIR) reviews your draft,this section will be one of their major focuses. Don't gloss over thesection, or say things like "use TLS to get security" without explaining howthe protocol uses TLS and what it provides. SeeBCP 72, "Guidelines forWriting RFC Text on Security Considerations", for more information on writinggood security considerations sections.

Also, a draft might have a "Privacy Considerations" section.An Informational RFC,RFC 6973: Privacy Considerations for Internet Protocols, written by theIAB, is intended to raise the general awareness of privacy on theInternet. It also provides advice for when a draft should have anexplicit privacy section.

Some drafts benefit from having an "Implementation Status" section,as explained byBCP 205: Improving Awareness of Running Code: The Implementation StatusSection.

More detail on the required content can be foundonline.

6.4 Standards-Track RFCs

If the IESG approves the draft to become a standards-track RFC, they ask theRPC to publish it as aProposed Standard.

Don't be surprised if a particular standard doesn't progress from ProposedStandard to Internet Standard. To become an Internet Standard, an RFC musthave multiple interoperable implementations and the unused features in theProposed Standard must be removed; there are additional requirements listedinBCP 9. Most of theprotocols in common use are Proposed standards and never move forward. Thismay be because no one took the time to try to get them to Internet Standard,or some of the normative references in the standard are still at Proposedstandard, or it may be that everyone found more important things to do.

6.5 RFCs Other than Standards-Track

As mentioned earlier, not all RFCs are standards. In fact, many importantRFCs are not on the standards track at all. At the time of writing, thereare also categories for Informational, Experimental, Best Current Practice,and Historical for standards that are no longer recommended for use. Therole of Informational RFCs can be confusing, and people sometimes refer tothem as "standards," when they are not.

Experimental RFCs are for specifications that are interesting, but for whichit is unclear if there will be widespread deployment, or if they will scale towork after such deployment. That is, a specification might solve a problem,but there might not be IETF consensus that the problem is worth solving orthat the specification is complete enough to address the problem.Experimental RFCs are also used to get people to experiment with a technologythat looks like it might be standards-track material, but for which there arestill unanswered questions.

The IESG has createdguidelines that can help choose between Informational and Experimental classification. This is a short informal read, and if are not sure whereyour document fits, it is worth reading.

Finally, there are two sub-series of RFCs: Best Current Practice(BCP) and Internet Standards (STD). BCP describes the application of varioustechnologies in the Internet, and are also commonly used to document the manyparts of the IETF process. The STD sub-series was created to identify RFCsthat do in fact specify Internet standards.

These are an example of the aphorism that everything in computer science canbe solved by a layer of indirection. For example, a single BCP can refer toone or more RFCs, and the specific RFCs can change such as when a new versionof a protocol is published. Likewise, some STDs are actuallysets of more than one RFC, and the "standard" designation applies to thewhole set of documents.

7 How to Contribute to the IETF

7.1 What You Can Do

Read: Review the Internet-Drafts in your area of expertise and comment onthem in the Working Groups. Participate in the discussion in a friendly,helpful fashion, with the goal being the best Internet standards possible.Listen much more than you speak. If you disagree, debate the technicalissues: never attack the people.

Implement: Write programs that use the current Internet standards. Thestandards aren't worth much unless they are available to Internet users.Implement even the "minor" standards, since they will become less minor ifthey appear in more software. Report any problems you find with the standardsto the appropriate Working Group so that the standard can be clarified inlater revisions. Remember the tenet, "rough consensus and running code,"so you can help support the standards you want to become morewidespread by creating more running code. You can help the development ofprotocols before they become standards by implementing I-Ds (but not doingwide-spread deployment) to ensure that the authors have done a good job. Ifyou find errors or omissions, offer improvements based on your implementationexperience. A great way to get involved in this is by participating inthe Hackathons.

Write: Edit or co-author Internet-Drafts in your area of expertise. Dothis for the benefit of the Internet community, not to get your name (or,even worse, your company's name) on a document. Draft authors receive kindsof technical (and, sadly, sometimes personal) criticism. Take the technicalcomments with equanimity and use it to improve your draft in order to producethe best and most interoperable standard, and ignore the personal ones.

7.2 What Your Company Can Do

Share: Avoid proprietary standards. If you are an implementor, exhibit astrong preference for IETF standards. If the IETF standards aren't as good asthe proprietary standards, work to make the IETF standards better. If you'rea purchaser, avoid products that use proprietary standards that compete withthe open standards of the IETF and tell the vendors that you are doing so.

Open Up: If your company owns a patent that is used in an IETF standard,convince the company to make the patent available at no cost to anyone who isimplementing the standard. Patents have previously caused many seriousproblems for Internet standards because they prevent some companies frombeing able to freely implement them. Fortunately, many companies havegenerously offered unlimited licenses for particular patents in order to helpthe IETF standards flourish. These companies are usually rewarded withpositive publicity for the fact that they are not as greedy or short-sightedas other patent-holders.

Support: The IETF hassponsorshipopportunities andan endowmentwhich can also take individual-sized donations.Become a member of ISOC. Urge any company that hasbenefited from the Internet to contribute, since this has the greatestfinancial benefit for the group. It will, of course, also benefit theInternet as a whole.

8 IETF and the Outside World

While some IETF participants would like to think otherwise, the IETFdoes not exist in a standards vacuum. This section discusses two importantgroups.

8.1 IETF and Other SDOs

There are many other standards organizations whose decisions affect theInternet. Some of them ignored the Internet for a long time and now want toget a piece of the action. In general, the IETF tries to have cordialrelationships with other SDOs. This isn't always easy, since they usuallyhave different structures and processes than the IETF does, and the IETF ismostly run by volunteers who would probably prefer to write standards ratherthan meet with representatives from other bodies. Even so, many SDOs make agreat effort to interact well with the IETF despite the obvious culturaldifferences.

As stated inBCP 39,the IAB Charter:"Liaisons are kept as informal as possible and must be ofdemonstrable value in improving the quality of IETF specifications." Inpractice, the IETF prefers liaisons to take place directly at the WGlevel, with formal relationships and liaison documents in a backup role. Thebest place to check to see whether the IETF has any formal liaison at all isthe list ofIETF liaisons.

At the time of this writing, the IETF has around two dozen liaisons. Some ofthese liaison tasks fall to the IESG, whereas others fall to the IAB.Full details about the processes for dealing with other SDOs can befound inBCP 102andBCP 103.

8.2 Press Coverage of the IETF

Given that the IETF is one of the best-known bodies that is helping move theInternet forward, it's natural for the media to cover its actions. But it canbe hard to cover the IETF; a common mistake is reporting an individual'sInternet-Draft as something the IETF is working on, or that the IETF hasapproved a new standard when it was an Informational or Individual RFC.Often, the press is not really to blame for the problem, as they might havebeen alerted to the story by a company trying to get publicity for aprotocol, or they see the latest "controversy" on social media.

Reporters who want to find out about "what the IETF is doing" on a particulartopic would be well-advised to talk to more than one person who is active onthat topic in the IETF, and should probably try to talk to the WG chair inany case. It's impossible to determine what will happen with a draft bylooking at the draft or talking to the draft's author. Fortunately, all WGshave archives that a reporter can look through for recent indications aboutwhat the progress of a draft is; unfortunately, few reporters have the timeor inclination to do this kind of research.

Reporters looking for information about the IETF, or pointers to IETFparticipants working on a particular topic relevant to the IETF, should senda message tomedia@ietf.org, and a fullpage of contacts for a variety of needs is availableonline. Replies are usually sentwithin a day. Even if a direct answer to a particular query is not available,pointers to resources or people who can provide more information about atopic are often provided.

Acknowledgements

The next phase of work to welcome new participants to the IETF builds on and gratefully acknowledges everyone who has contributed to the Tao, and other efforts to help newcomers to the IETF become engaged and productive participants.

We acknowledge all of the past "Tao of the IETF" editors:

We also acknowledge all the work of the translators that made the Tao accessible to many different audiences.

Finally, we also want to acknowledge the work of countless contributors over the years.

Authors' Addresses

Niels ten Oever
University of Amsterdam
Email:mail@nielstenoever.net
Greg Wood
IETF Administration LLC
Email:ghwood@staff.ietf.org

[8]ページ先頭

©2009-2025 Movatter.jp