doc: Add RFC documents

1 files changed, 2118 insertions, 0 deletions

diff --git a/doc/rfc/rfc9592.txt b/doc/rfc/rfc9592.txt
new file mode 100644
index 0000000..a2af7a3
--- /dev/null
+++ b/doc/rfc/rfc9592.txt
@@ -0,0 +1,2118 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      N. ten Oever
+Request for Comments: 9592                       University of Amsterdam
+Obsoletes: 6722                                                  G. Wood
+Category: Informational                          IETF Administration LLC
+ISSN: 2070-1721                                                June 2024
+
+
+                      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 at
+   https://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
+   2.  Reasons for Retirement
+     2.1.  Infrequent Updates
+     2.2.  Unwieldy Format
+     2.3.  Changing Participation Modes
+   3.  Going Forward
+     3.1.  New Communications Opportunities
+   4.  Conclusion
+   5.  Security Considerations
+   6.  IANA Considerations
+   7.  Informative References
+   Appendix A.  Last Edition of the Tao
+     Abstract
+     1 Introduction
+       1.1 Acronyms and Abbreviations Used in the Tao
+     2 What is the IETF?
+       2.1 Humble Beginnings
+       2.2 The Hierarchy
+       2.3 IETF Mailing Lists
+     3 IETF Meetings
+       3.1 Registration
+       3.2 Take the Plunge and Stay All Week!
+       3.3 Newcomer Training
+       3.4 Dress Code
+       3.5 Working Group Meetings
+       3.6 Seeing Spots Before Your Eyes
+       3.7 Terminal Room
+       3.8 Meals and Snacks
+       3.9 Social Event
+       3.10 Agenda
+       3.11 EMODIR to the Rescue
+       3.12 Where Do I Fit In?
+       3.13 Proceedings
+       3.14 Other General Things
+       3.15 Remote Participation
+     4 Working Groups
+       4.1 Working Group Chairs
+       4.2 Getting Things Done in a Working Group
+       4.3 Working Group Documents
+       4.4 Preparing for Working Group Meetings
+       4.5 Working Group Mailing Lists
+       4.6 Interim Working Group Meetings
+     5 BOFs and Dispatching
+     6 RFCs and Internet-Drafts
+       6.1 The Overall Process
+       6.2 Common Issues
+       6.3 Writing an Internet-Draft
+       6.4 Standards-Track RFCs
+       6.5 RFCs Other than Standards-Track
+     7 How to Contribute to the IETF
+       7.1 What You Can Do
+       7.2 What Your Company Can Do
+     8 IETF and the Outside World
+       8.1 IETF and Other SDOs
+       8.2 Press Coverage of the IETF
+   Acknowledgements
+   Authors' Addresses
+
+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:
+
+   *  [RFC1539] in October 1993,
+   *  [RFC1718] in November 1994,
+   *  [RFC3160] in August 2001, and
+   *  [RFC4677] in September 2006.
+
+   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 in Appendix 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, January 1993,
+              <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, October 1993,
+              <https://www.rfc-editor.org/info/rfc1539>.
+
+   [RFC1718]  IETF and G. Malkin, "The Tao of IETF - A Guide for New
+              Attendees of the Internet Engineering Task Force",
+              RFC 1718, DOI 10.17487/RFC1718, November 1994,
+              <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, August 2001,
+              <https://www.rfc-editor.org/info/rfc3160>.
+
+   [RFC4677]  Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
+              Guide to the Internet Engineering Task Force", RFC 4677,
+              DOI 10.17487/RFC4677, September 2006,
+              <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, August 2012,
+              <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 meetings now averages between 1000 and
+   1500 participants (https://datatracker.ietf.org/stats/meeting/
+   overview/).  At any given meeting, around 200 attendees are
+   _newcomers_ (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-face meetings at all -- especially since the COVID-19
+   pandemic when meetings were completely online for a while.  There are
+   also many participants who solely focus on the mailing lists of
+   various IETF Working Groups.  Since the inner workings of Working
+   Groups can be hard for newcomers to understand, this document
+   provides the mundane bits of information that newcomers will need in
+   order to become active participants.  The IETF website also has a lot
+   of newcomer information (https://www.ietf.org/about/participate/get-
+   started/) 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 are expected to remain consistent over time, practical
+   details may well have changed by the time you read it; for example, a
+   web-based tool may have replaced an email address for requesting some
+   sort of action.
+
+   Many types of IETF documentation are mentioned here.  The IETF
+   publishes its technical documentation as RFCs, still known by their
+   historical term _Requests for Comments_.  (Sometimes people joke that
+   it stands for _Request for Compliance_.) STDs are RFCs identified as
+   "standards", and BCPs are RFCs that represent thoughts on Best
+   Current Practices in the Internet.  Both STDs and BCPs are also RFCs.
+   For example, BCP 9 (https://www.rfc-editor.org/info/bcp9) points to a
+   collection of RFCs that describe the IETF's standardization
+   processes.  See RFCs 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.
+
+      +=======+=====================================================+
+      | Term  | Meaning                                             |
+      +=======+=====================================================+
+      | AD    | Area Director                                       |
+      +-------+-----------------------------------------------------+
+      | BCP   | Best Current Practice (a type of RFC)               |
+      +-------+-----------------------------------------------------+
+      | BOF   | Birds of a Feather                                  |
+      +-------+-----------------------------------------------------+
+      | IAB   | Internet Architecture Board                         |
+      +-------+-----------------------------------------------------+
+      | IANA  | Internet Assigned Numbers Authority                 |
+      +-------+-----------------------------------------------------+
+      | IASA  | IETF Administrative Support Activity                |
+      +-------+-----------------------------------------------------+
+      | ICANN | Internet Corporation for Assigned Names and Numbers |
+      +-------+-----------------------------------------------------+
+      | I-D   | Internet-Draft                                      |
+      +-------+-----------------------------------------------------+
+      | IESG  | Internet Engineering Steering Group                 |
+      +-------+-----------------------------------------------------+
+      | IPR   | Intellectual property rights                        |
+      +-------+-----------------------------------------------------+
+      | IRSG  | Internet Research Steering Group                    |
+      +-------+-----------------------------------------------------+
+      | IRTF  | Internet Research Task Force                        |
+      +-------+-----------------------------------------------------+
+      | ISOC  | Internet Society                                    |
+      +-------+-----------------------------------------------------+
+      | RFC   | Request for Comments                                |
+      +-------+-----------------------------------------------------+
+      | STD   | Standard (a type of RFC)                            |
+      +-------+-----------------------------------------------------+
+      | WG    | Working Group                                       |
+      +-------+-----------------------------------------------------+
+
+                                  Table 1
+
+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 the engineering and evolution of
+   Internet technologies.  It is the principal body engaged in the
+   development of new Internet standard specifications.  The IETF is
+   unusual in that it exists as a collection of meetings (both in-person
+   and 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 all over the world and from many different parts of the Internet
+   industry.  The IETF conducts its work solely in English.  See Where
+   do I fit in? for information about the ways that many people fit into
+   the IETF.
+
+   Quoting from RFC 3935: A Mission Statement for the IETF
+   (https://www.rfc-editor.org/info/rfc3935): "the overall goal of the
+   IETF is to make the Internet work better.  Its mission is to produce
+   high quality, relevant technical and engineering documents that
+   influence the way people design, use, and manage the Internet in such
+   a way as to make the Internet 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 and
+      technical problems in the Internet.
+
+   *  Specifying the development or usage of protocols and the near-term
+      architecture to solve such technical problems for the Internet.
+
+   *  Making recommendations to the Internet Engineering Steering Group
+      (IESG) regarding the standardization of protocols and protocol
+      usage in the Internet.
+
+   *  Facilitating technology transfer from the Internet Research Task
+      Force (IRTF) to the wider Internet community.
+
+   *  Providing a forum for the exchange of information within the
+      Internet community among vendors, users, researchers, agency
+      contractors, operators, and network managers.
+
+   RFC 3935 further states that the Internet isn't value-neutral, and
+   neither is the IETF.  The IETF wants the Internet to be useful for
+   communities that share our commitment to openness and fairness.  The
+   IETF embraces technical concepts such as decentralized control, edge-
+   user empowerment and sharing of resources, because those concepts
+   resonate with the core values of the IETF community.  These concepts
+   have little to do with the technology that's possible, and much to do
+   with the technology that the IETF chooses to create.
+
+   In many ways, the IETF runs on the beliefs of its participants.  One
+   of the founding beliefs is embodied in an early quote about the IETF
+   from David Clark: "We reject kings, presidents and voting.  We
+   believe in rough consensus and running code."  Another early quote
+   that has become a commonly-held belief in the IETF comes from Jon
+   Postel: "Be conservative in what you send and liberal in what you
+   accept."
+
+   There is no membership in the IETF.  Anyone may sign up to working
+   group mailing lists, or register for a meeting and then attend.  The
+   closest thing there is to being an IETF member is being a participant
+   on the IETF or Working Group mailing lists.  This is where the best
+   information about current IETF activities and focus can be found.
+
+   Of course, no organization can be as successful as the IETF is
+   without having some sort of structure.  In the IETF's case, that
+   structure is provided by other supporting organizations, as described
+   in RFC 2028: The Organizations Involved in the IETF Standards Process
+   (https://www.rfc-editor.org/info/rfc2028).  Please note that RFC 2028
+   is outdated and being revised.
+
+   The IETF web site (https://www.ietf.org) is the best source for
+   information about upcoming IETF meetings and newcomer materials.  The
+   IETF Datatracker (https://datatracker.ietf.org/) is the best source
+   for information about Internet-Drafts, RFCs, and Working Groups.
+
+   One more thing that is important for newcomers: the IETF in no way
+   "runs the Internet," despite what some people mistakenly might say.
+   The IETF makes voluntary standards that are often adopted by Internet
+   users, network operators, and equipment vendors, and it thus helps
+   shape the trajectory of the development of the Internet.  But in no
+   way does the IETF control, or even patrol, the Internet.  If your
+   interest in the IETF is because you want to be part 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 Groups was introduced at the 5th IETF meeting at
+   the NASA Ames Research Center in California in February 1987.  The
+   7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the
+   first meeting with more than 100 attendees.
+
+   After the Internet Society (https://www.internetsociety.org) (ISOC)
+   was formed in January 1992, the IAB proposed to ISOC that the IAB's
+   activities should take place under the auspices of the Internet
+   Society.  During INET92 in Kobe, Japan, the ISOC Trustees approved a
+   new charter for the IAB to reflect the proposed relationship.
+
+   The IETF met in Amsterdam, The Netherlands, in July 1993.  This was
+   the first IETF meeting held in Europe, and the US/non-US attendee
+   split was nearly 50/50.  The IETF first met in Oceania (in Adelaide,
+   Australia) in 2000, the first meeting in Asia (in Yokohama, Japan)
+   was in 2002, and the first meeting in Latin America (in Buenos Aires,
+   Argentina) was in 2016.  So far, the IETF has never met in Africa.
+
+   The IETF currently has a "1-1-1" meeting policy where the goal is to
+   distribute the meetings equally between North America, Europe, and
+   Asia.  This policy is mainly aimed at distributing the travel effort
+   for the existing IETF participants who physically attend meetings and
+   for distributing the timezone difficulty for those who participate
+   remotely.  The IETF has also met in Latin America and Oceania, but
+   these continents are currently not part of the 1-1-1 rotation
+   schedule.  More information on picking the venue and the meeting
+   policy can be found in RFC 8718: IETF Plenary Meeting Venue Selection
+   Process (https://www.rfc-editor.org/info/rfc8718) and RFC 8719: High-
+   Level Guidance for the Meeting Policy of the IETF (https://www.rfc-
+   editor.org/info/rfc8719).
+
+   Remote participation in IETF meetings has been growing significantly
+   in the past few years, thanks in part to the ongoing effort to
+   improve the tools and processes 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,
+   membership organization that supports and promotes the development of
+   the Internet as a global technical infrastructure.  The mission of
+   ISOC is "to promote the open development, evolution, and use of the
+   Internet for the benefit of all people throughout the world."  One of
+   the ways that ISOC does this is through financial support of the
+   IETF.
+
+   The IETF Administration LLC (https://www.ietf.org/about/
+   administration/) (IETF LLC) is a "disregarded entity" of ISOC, which
+   means it is treated as a branch or division for tax purposes.  The
+   IETF LLC has no role in the oversight or steering of the standards
+   process, the appeal chain, the confirming bodies for existing IETF
+   and IAB appointments, the IRTF, or ISOC's memberships in other
+   organizations.  Rather, the IETF LLC, as overseen by its Board of
+   Directors, is responsible for staffing and contracts with places like
+   hotels to host IETF meetings.  Most of the day-to-day activities are
+   delegated to the IETF Executive Director.
+
+   Responsibilities of the IETF LLC include:
+
+   *  Supporting the ongoing operations of the IETF, including meetings
+      and non-meeting activities.
+
+   *  Managing the IETF's finances and budget.
+
+   *  Raising money on behalf of the IETF.
+
+   *  Establishing and enforcing policies to ensure compliance with
+      applicable laws, regulations, and rules.
+
+   The IETF and ISOC continue to be strongly aligned on key principles.
+   ISOC initiatives related to the IETF continue to support
+   participation in, and deployment 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 the Internet standards process.  However, the IESG doesn't
+   exercise much direct leadership, such as the kind you will find in
+   many other standards organizations.  As its name suggests, its role
+   is to set directions rather than to give orders.  The IESG gets WGs
+   started and finished, ratifies or steers the output from the IETF's
+   Working Groups (WGs), and makes sure that non-WG I-Ds that are about
+   to become RFCs are correct.
+
+   Check the IESG web pages (https://www.ietf.org/about/groups/iesg) to
+   find up-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
+   the Nominations Committee (NomCom) and are appointed for two years.
+   The process for choosing the members of the IESG is detailed in BCP
+   10 (https://www.rfc-editor.org/info/bcp10).
+
+   The current Areas and abbreviations are shown below, and more details
+   (https://www.ietf.org/topics/areas/) are on the IETF web site.
+
+     +======================+========================================+
+     | Area                 | Description                            |
+     +======================+========================================+
+     | Applications and     | Protocols seen by user programs, such  |
+     | Real-Time Area (art) | 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       | Network management, AAA, and various   |
+     | Management (ops)     | 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         |
+     +----------------------+----------------------------------------+
+
+                                  Table 2
+
+   Because the IESG reviews all Internet-Drafts before they become RFCs,
+   ADs have quite a bit of influence.  The ADs for a particular Area are
+   expected to know 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 are responsible and assist working
+   groups and chairs with charter and milestone reviews.  Some people,
+   therefore, shy away from directly engaging with Area Directors.
+   Don't -- they can be an important resource and help you find the
+   person or the answer that you're looking for.  They are, however,
+   often very busy during meetings, and so an email to schedule a
+   meeting can be useful, or just ask your questions.
+
+   The entire IESG reviews each Internet-Draft (I-D or "draft") that is
+   proposed to become an RFC and should be aware of general trends that
+   can be gleaned from the collective work products of the IETF.  For
+   IETF produced RFCs, as part of the document reviews, ADs place
+   ballots that may contain comments on documents.  The AD enters a
+   position that may be _YES_, _NO OBJECTION_, _DISCUSS_, _ABSTAIN_, or
+   _RECUSE_ as the result of their review.  Any AD may record a
+   _DISCUSS_ ballot position against a draft if they have serious
+   concerns and would like to discuss these concerns.  It is common for
+   documents to be approved with one or two _YES_ ballots, and the
+   majority of the remaining IESG balloting _NO OBJECTION_.  An IETF
+   blog post (https://www.ietf.org/blog/handling-iesg-ballot-positions/)
+   provides advice on how draft authors could handle the various ballot
+   positions.
+
+   Another important job of the IESG is to watch over the output of all
+   the WGs to help prevent IETF protocols that are at odds with each
+   other.  This is why ADs are supposed to review the I-Ds coming out of
+   Areas other than their own, and each Area has a _directorate_, a set
+   of experienced volunteers who review 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 the Working Groups and the scrutiny that the WG review gets from
+   the ADs.
+
+2.2.3 Internet Architecture Board (IAB)
+
+   The IAB (https://www.iab.org) is responsible for keeping an eye on
+   the "big picture" of the Internet, and it focuses on long-range
+   planning and coordination among the various areas of IETF activity.
+   The IAB stays informed about important long-term issues in the
+   Internet, and it brings these topics to the attention of people it
+   thinks should know about them.
+
+   IAB members pay special attention to emerging activities in the IETF.
+   When a new IETF Working Group is proposed, the IAB reviews its
+   charter for architectural consistency and integrity.  Even before the
+   group is chartered, the IAB members are more than willing to discuss
+   new ideas with the people proposing them.
+
+   The IAB also sponsors and organizes the Internet Research Task Force
+   (https://www.irtf.org) (IRTF) and convenes invitational workshops
+   that provide in-depth reviews of specific Internet architectural
+   issues.  Typically, the workshop reports make recommendations to the
+   IETF community and to the IESG.  The IAB keeps the community 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
+   the NomCom 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 the IANA
+   (https://www.iana.org).  Many Internet protocols require that someone
+   keep track of protocol items that were added after the protocol came
+   out.  Typical examples of the kinds of registries needed are for TCP
+   port numbers and MIME types.  IANA's work on behalf of the IETF is
+   overseen by the IAB.  There is a joint group
+   (https://datatracker.ietf.org/group/ietfiana/about/) that advises
+   IANA.  IANA is funded by ICANN (https://www.icann.org).
+
+   Even though being a registry may not sound interesting, many IETF
+   participants will testify to how important IANA has been for the
+   Internet.  Having a stable, long-term repository run by careful and
+   conservative operators makes it much easier for people to experiment
+   without worrying about 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
+   one person, which is why you will still see the term _RFC Editor_;
+   IETFers are fond of their history.  Also, if you are a document
+   author, you will most commonly come in contact with people
+   responsible for editing your draft.  Another important role is to
+   provide one definitive repository (https://www.rfc-editor.org) 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 Independent streams.  It is likely that there will soon be a
+   fifth source, which will be for documents on the RFC series itself.
+   Only documents coming directly from the IETF through Working Groups,
+   or sponsored by ADs, can have IETF consensus and be described as IETF
+   specifications or standards.
+
+   Once an RFC is published, it is never revised.  If the specification
+   it describes changes, the standard will be re-published in another
+   RFC that "obsoletes" the first.  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 to the 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
+   is being revised under an IAB Program
+   (https://datatracker.ietf.org/group/rfcefdp/about/).  In this
+   revision, there is a position hired by the IETF LLC known as the RFC
+   Series Editor, who is advised by a couple of groups.  As a newcomer,
+   and potential 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 IETF
+   Secretariat provides day-to-day logistical support, which mainly
+   means coordinating face-to-face meetings and running the IETF
+   presence on the web, including the IETF web site
+   (https://www.ietf.org), mailing lists, the repository for Internet-
+   Drafts, and so on.  The Secretariat also provides administrative
+   assistance to the IESG and others.
+
+   The Secretariat is contracted by the IETF LLC.
+
+2.2.7 IETF Trust
+
+   The IETF Trust (https://trustee.ietf.org) was set up to hold and
+   license the intellectual property of the IETF, such as trademarks
+   (the IETF logo, etc.) and copyrights.  The trust is a stable,
+   legally-identifiable entity.  Most participants never interact with
+   the IETF Trust, beyond seeing it mentioned in RFC boilerplate.  This
+   is a good sign, and indicates that they 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 the IETF
+   announcement mailing list (https://www.ietf.org/mailman/listinfo/
+   ietf-announce).  This is where all of the meeting information, RFC
+   announcements, and IESG Protocol Actions and Last Calls are posted.
+   This list is strongly moderated, and only the Secretariat and a small
+   number of IETF leaders can approve messages sent to the announcement
+   list, although those messages can come from a variety of people.
+
+   There is also a general discussion list
+   (https://www.ietf.org/mailman/listinfo/ietf) that is unmoderated.
+   This means that everyone can express their opinions about issues
+   affecting the Internet.  As an open discussion forum, it sometimes
+   spins out of control and it helps to be quick on the _DELETE MESSAGE_
+   button while also being slow to take offense.  The mailing list does
+   have a charter (https://www.rfc-editor.org/info/bcp45), however,
+   which points out that it is not a place for companies or individuals
+   to solicit or advertise.  As of this writing, the charter is being
+   revised.  It is lightly moderated by two people appointed by the IETF
+   Chair; they used to be called the Sargent At Arms (SAA), and you
+   might see that term sometimes.  There is also a process for banning
+   persistent offenders from the list, but fortunately this is extremely
+   rare.
+
+   There are also subset lists.  The i-d-announce
+   (https://www.ietf.org/mailman/listinfo/i-d-announce) list only posts
+   when a new Internet-Draft is submitted.  It is moderated.  The last-
+   call (https://www.ietf.org/mailman/listinfo/last-call) list is not
+   moderated, and is for discussion of IETF Last Calls (the stage when
+   the IETF community is given one last chance to comment on a draft
+   before it is published as an RFC).
+
+   Every Working Group has its own mailing list.
+
+   Every IETF mailing list is archived.  (Unfortunately, the archives
+   for some lists from many years ago, when the IETF did not have its
+   own servers, have been lost.)
+
+   Even though the IETF mailing lists "represent" the IETF participants
+   at large, it is important to note that attending an IETF meeting does
+   not mean you'll be automatically added to any list; you'll have to
+   "opt in" directly.
+
+3 IETF Meetings
+
+   The computer industry is rife with conferences, seminars,
+   expositions, and all manner of other kinds of meetings.  IETF face-
+   to-face meetings are not like these.  The meetings, held three times
+   a year, are week-long gatherings with the primary goals of helping
+   Working Groups get their tasks done, and promoting a fair amount of
+   mixing among the WGs and the Areas.  IETF meetings are of little
+   interest to sales and marketing folks, but of high interest to
+   engineers and developers.
+
+   For many people, IETF meetings are a breath of fresh air when
+   compared to the standard computer industry conferences.  There is no
+   exposition hall, few tutorials, 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 hotel lobby, but drink whatever you
+   want) is highly conducive to collaboration.
+
+   On the other hand, IETFers can sometimes be surprisingly direct,
+   sometimes verging on rude.  To build a climate in which people of
+   many different backgrounds are treated with dignity, decency, and
+   respect, the IETF has an anti-harassment policy
+   (https://www.ietf.org/blog/ietf-anti-harassment-policy), a code of
+   conduct (https://www.rfc-editor.org/info/bcp54), and an Ombudsteam
+   (https://www.ietf.org/contact/ombudsteam) that you can reach out to.
+
+   The general flow of an IETF meeting is that it begins with an IETF
+   Hackathon (https://www.ietf.org/how/runningcode/) on Saturday and
+   Sunday, tutorials and an informal gathering on Sunday, and WG and BoF
+   meetings Monday through Friday.  WG meetings last for between 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 the agenda for
+   their meeting time(s).
+
+   There is a plenary session during the week, sometimes two.  Either
+   the first part, or a separate Technical Plenary, will have one or
+   more technical presentations on topics of interest to many Working
+   Groups.  This is organized by the IAB.  The Administrative Plenary is
+   organized by the IETF Chair, and will have greetings from the meeting
+   sponsor, reports on meeting attendance and IETF finances, and
+   progress reports from most groups mentioned in the "Hierarchy"
+   section above.  This ends with an "open mic" session, with the
+   various groups on stage.  This is a good time to share administrative
+   concerns; 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 available online
+   (https://www.ietf.org/how/meetings/upcoming/), and they are also
+   announced on the _ietf-announce_ mailing list mentioned above.
+
+   Note that COVID-19 disrupted the in-person meetings.  After several
+   virtual or online meetings, the IETF tried its first hybrid meeting,
+   in Vienna, in March 2022.
+
+3.1 Registration
+
+   To attend an IETF meeting, either online or in person, you have to
+   register and pay a registration fee.  If you cannot afford the online
+   registration fee, you can apply for a fee waiver during the
+   registration process.  The meeting site (if the meeting is not purely
+   online) is generally announced at several months ahead of the meeting
+   -- earlier if possible.  An announcement goes out via email to the
+   _ietf-announce_ mailing list, and information is posted on the IETF
+   web site (https://www.ietf.org), that same day.  Upcoming meeting
+   locations are also mentioned at the plenary, and the host for the
+   next meeting often gives a welcome.
+
+   You can register online at the IETF website, or in person throughout
+   the week.  There are different fee schedules for early-bird,
+   latecomers, single-day, and so on.  The general registration fee
+   covers all of the week's meetings, the Sunday evening _Welcome
+   Reception_, and afternoon beverage and snack breaks.
+
+   The IETF and related organizations are committed to transparency and
+   protecting the privacy of individuals.  For information about the
+   personal data that is collected, and how it is managed, please see
+   the privacy statement (https://www.ietf.org/privacy-statement/).
+
+   You might also consider subscribing to the meeting-specific email
+   list, which is presented as an option when you register to
+   participate in the meeting either in-person or remotely.  Discussions
+   on the meetings list can be high volume and fairly wide-ranging about
+   meeting-specific issues, but it is also a channel for sharing
+   information that many find useful to understand what is going on
+   during the meeting itself.  Topics often include information about
+   local mass transit, interesting sites to see, desire to buy or sell a
+   social 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 on Saturday for the hackathon.  Sunday is the day for the
+   newcomer's tutorial, as well the Quick Connections session where
+   newcomers get to meet with experienced IETF participants.  After
+   these sessions there is the welcome reception, a popular event where
+   you can get a small bite to eat and socialize with other attendees.
+
+   During registration, you will be asked to confirm that you agree to
+   follow the _Note Well_. You can also read it, anytime, online
+   (https://www.ietf.org/about/note-well/).  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 gets later 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 cork boards that are usually near the IETF registration desk.
+   These cork boards will also have last-minute meeting changes and room
+   changes.  The agenda is available online, and changes can happen up
+   to the last minute, such as cancelling a WG meeting.
+
+   You can also turn in lost-and-found items to the registration desk.
+   At the end of the meeting, anything left over from the lost-and-found
+   will usually be turned over to the hotel or brought back to the
+   Secretariat's office.  Incidentally, the IETF registration desk is
+   often a convenient place to arrange to meet people.  If someone says
+   "meet me at registration," you should clarify if they mean the IETF
+   registration desk, or the hotel registration desk: This has been a
+   common cause of missed connections.
+
+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 following weekends, and unofficial "side meetings" can
+   also be scheduled during the week.  It is best to plan to be present
+   the whole week, to benefit from cross-fertilization between WGs and
+   from hallway discussions (both offline as well as in online
+   environments such as the _gather.town_ website).  As noted below, the
+   agenda is fluid, and there have been instances of participants
+   missing important sessions due to last-minute scheduling changes
+   after their travel plans were fixed.  Being present the whole week is
+   the only way to avoid this annoyance.
+
+   If you cannot find meetings all week to interest you, you can still
+   make the most of the IETF meeting by working between sessions.
+   Almost every attendee has a laptop, and it is common to see many of
+   them in the terminal room or in the 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 places of
+   the meeting venue (restaurants, coffee shops, and so on), so catching
+   up on email when not in meetings is a fairly common task for IETFers.
+
+   Note that many people use their laptops actively during meeting
+   sessions for practical purposes such as consulting drafts.  Power
+   strips in all meeting rooms and hotel rooms will provide only the
+   sockets permitted by local regulations, 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 is
+   especially designed for them.  The tutorial is organized and
+   conducted by the IETF Education, Mentoring, and Outreach Directorate
+   (_EMODIR_) team and is intended to provide useful introductory
+   information.  The session covers the structure of the IETF, how to
+   get the most out of the meeting, and many other essential and
+   enlightening topics for new IETFers.  The IETF has a YouTube channel
+   (https://www.youtube.com/user/ietf) which has the previous tutorials.
+   This has recently been broken down into four 15-minute segments
+   (https://www.youtube.com/watch?v=MW1cDLmr91c&list=PLC86T-
+   6ZTP5imxIwnF0mYxWVp0sbqDR0J&pp=iAQB) which might be easier to view.
+
+   _Quick Connections_ is a session limited to newcomers and experienced
+   IETF participants.  It is a great chance to meet people, and
+   establish contacts that can be useful during the rest of the week.
+   Registration is required as 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 out of place if they show up Monday morning in suits.  The
+   general rule is "dress for casual comfort."  Note that the hotel air
+   conditioning might mean bringing a sweater or other covering as well.
+
+3.5 Working Group Meetings
+
+   The heart of an IETF meeting is the WG meetings themselves.
+   Different WGs chairs have very different styles, so it is impossible
+   to generalize how a WG meeting will feel.  All WGs have agendas,
+   however, and most will follow the following approach.
+
+   At the beginning of the meeting, the chair will pass around the _blue
+   sheets_, which are paper forms on which everyone writes their name
+   and their affiliation.  These are archived and used for planning
+   capacity needs for the next time the WG meets.  In very rare cases,
+   they have been used to indicate exactly who showed up.  When you are
+   handed the sheet, sign your name and pass it along in the same
+   direction.  If you arrive after the start, at the end of the meeting
+   you can go up front and sign it then.  For virtual attendance using
+   the _MeetEcho_ video conference system, attendance is handled by
+   accessing the application.
+
+   After the blue sheets, there are calls for volunteers to take
+   minutes.  More than one person can do so, and they are often done on
+   a Web page using a collaborative editing app.  Taking minutes can be
+   a good way to ensure you follow the discussions without distraction!
+   The link to the web page will be part of the WG entry that is part of
+   the online meeting agenda.  There is also a chance to make any last-
+   minute updates to the agenda.  This is known as "agenda bashing."
+   Finally, there will be a review of the Note Well.  The order in which
+   these things happen can vary, but they are all done before the
+   meeting really "starts."
+
+   To speak during a meeting, go to the microphone(s) located near the
+   middle of the room.  For controversial topics, there will be a line
+   at the mic, but do not hesitate to be the first person at the line if
+   you have a question or a contribution to the discussion.  The WG
+   chair or presenter will indicate when you can speak.  Although it
+   would be easier to just raise your hand from where you are sitting,
+   the mics perform a very useful task: they let the people listening
+   remotely and in the room hear your question or comment.  When you
+   first speak, say your name and affiliation for identification
+   purposes.  If you miss this, folks will often say "name!" to remind
+   you.  Don't be embarrassed 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 few people have more than one.  These dots identify people who have
+   volunteered to do extra work, such as being a WG chair, an IESG
+   member, and so on.  The colors have the meanings shown here.
+
+                 +========+=============================+
+                 | Color  | Meaning                     |
+                 +========+=============================+
+                 | Blue   | Working Group/BOF Chair     |
+                 +--------+-----------------------------+
+                 | Green  | Meeting Host/Sponsor        |
+                 +--------+-----------------------------+
+                 | Red    | IAB member                  |
+                 +--------+-----------------------------+
+                 | Yellow | IESG member                 |
+                 +--------+-----------------------------+
+                 | Pink   | IRSG member                 |
+                 +--------+-----------------------------+
+                 | Orange | Nominating Committee member |
+                 +--------+-----------------------------+
+                 | Black  | IETF LLC Board              |
+                 +--------+-----------------------------+
+
+                                 Table 3
+
+   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 wear these dots.  If the IAB and IESG members and Working Group
+   and BOF chairs didn't want to talk to anybody, they wouldn't be
+   wearing the dots in the first place!  Note, however, that IETF
+   meetings are usually intense times for Area Directors.  Talking to an
+   AD during an IETF meeting will often result in them asking you to
+   send email after the meeting ends.  Also, when you start a hallway
+   conversation with an Area Director (or even a WG chair, for that
+   matter), it is often good to give them about 30 seconds of context
+   for the discussion.
+
+   Near the registration area there are usually ribbons and markers so
+   that people 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 limited access 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.  The terminal room provides power strips, Ethernet ports, and
+   wifi (for the people who don't need Ethernet but want power).  What
+   it doesn't provide are terminals; the name is historical.  The help
+   desk in the terminal room is also a good place to ask questions about
+   network failures, although they 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 the food on their own since lunches and dinners are not included
+   in the registration fee.  In addition to socializing, dinner meetings
+   can be a good way to get additional work done.
+
+   If sponsorship for it is secured, the welcome reception provides
+   drinks and 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, and a similar one in the afternoon.
+
+   If you prefer to get out of the hotel for meals, the local host
+   usually provides 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 the IETF social event.  The social event is sometimes high-
+   tech-related event, or it might be in an art museum or a reception
+   hall.  Note, however, that not all IETF meetings have social events.
+
+   Newcomers to the IETF are encouraged to attend the social event.
+   Wear your name tag and leave your laptop behind.  The social event is
+   designed to give people a chance to meet on a social, rather than
+   technical, level.  The social ticket costs extra, is reserved at
+   registration time, and has limited capacity.  People looking to buy
+   or sell a social ticket often post to the email list, or on the
+   corkboards mentioned above.
+
+3.10 Agenda
+
+   The agenda for the IETF meetings is a very fluid thing.  It is
+   available on the web and through the IETF mobile apps starting a few
+   weeks before the meeting.  Of course, "final" in the IETF doesn't
+   mean the same thing as it does elsewhere in the world.  The final
+   agenda is simply the last version posted before the meeting.  The
+   Secretariat will post agenda changes on the bulletin board near the
+   IETF registration desk (reminder, not the hotel registration desk!).
+   These late changes are not capricious: they are made "just in time"
+   as session chairs and speakers become aware of unanticipated
+   conflicts.  The IETF is too dynamic for agendas to be tied down weeks
+   in advance.
+
+   A map showing the hotel layout and, specifically the meeting rooms,
+   is also available with the agenda.  Room assignments can change as
+   the agenda changes.  Some Working Groups meet multiple times during a
+   meeting, and every attempt is made to have a Working Group meet in
+   the same room for each session.
+
+3.11 EMODIR to the Rescue
+
+   If, after you finish reading this document, certain aspects of the
+   IETF still mystify you, you'll want to drop in on the on-site
+   training offered by the Education, Mentoring, and Outreach (EMODIR)
+   team.  In addition to the Newcomer training mentioned above, EMODIR
+   also hosts informal newcomer gatherings 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
+   newcomers and experienced IETFers alike.  These are also announced as
+   part of the program, and are usually on Sundays.
+
+   Finally, EMODIR runs the _IETF Guides_ program, pairing newcomers
+   with an experienced 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 call with your mentor before the
+   meeting, a meeting during the beginning of the meeting, and check in
+   some time during the meeting, so they can help you with any questions
+   you might have.
+
+   Details on EMODIR membership and charter are available online
+   (https://datatracker.ietf.org/group/emodir/about/).
+
+3.12 Where Do I Fit In?
+
+   The IETF is different things to different people.  There are many
+   people who have been very active in the IETF who have never attended
+   an IETF meeting, and you should not feel obligated to come to an IETF
+   meeting just to get a feel for the IETF.  If, however, you decide to
+   come, this document and RFC 4144: How to Gain Prominence and
+   Influence in Standards Organizations (https://www.rfc-
+   editor.org/info/rfc4144) provides some pointers on how to make your
+   meeting a success.  The following guidelines (based on stereotypes of
+   people in various industries) might help you decide whether you
+   actually want to come and, if so, what might be the best use of your
+   time at your first meeting.
+
+3.12.1 IT Managers
+
+   As discussed throughout this document, an IETF meeting is nothing
+   like any trade show you have attended.  IETF meetings are singularly
+   bad places to go if your intention is to find out what will be hot in
+   the Internet industry next year.  You can safely assume that going to
+   Working Group meetings will confuse you more than it will help you
+   understand what is happening, or will be happening, in the industry.
+
+   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 are responsible for technologies that are under
+   development in the IETF.  As these people read the current Internet-
+   Drafts and email traffic on the relevant Working Group lists, they
+   will get a sense of whether or not their presence would be worthwhile
+   for your company or for the Working Groups.
+
+3.12.2 Network Operators and ISPs
+
+   Knowledge of how networks are run is indispensable for the
+   development of new (versions of) protocols.  Especially if you work
+   for the type of network 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 might
+   be particularly relevant.
+
+   Finally, note that the IETF is increasingly focused on encrypting
+   network traffic, and that this has implications for operators.  A
+   fair amount of IETF work also covers many other parts of operations
+   of ISPs and large enterprises, and the input of operators from each
+   of these types of organizations is quite valuable to keep this work
+   vibrant and relevant.  Many of the best operations documents from the
+   IETF come from real-world operators, not vendors and academics.
+
+3.12.3 Networking Hardware and Software Vendors
+
+   The image of the IETF being mostly network researchers may have been
+   true in the distant past, but the jobs of today's attendees are
+   typically in industry.  In most areas of the IETF, employees of
+   vendors are the ones writing the protocols and leading the Working
+   Groups, so it's completely appropriate for vendors to attend.  If you
+   create Internet hardware or software, or run a service available on
+   the Internet, and no one from your company has ever attended an IETF
+   meeting, it behooves you to come to a meeting if for no other reason
+   than to tell the others how relevant the meeting was or was not to
+   your business.
+
+   This is not to say that companies should close up shop during IETF
+   meeting weeks so everyone can go to the meeting.  Marketing folks,
+   even technical marketing folks or pre-sales, are safe in staying away
+   from the IETF as long as some of the technical people from the
+   company are at the meeting.  Similarly, it isn't required, or likely
+   useful, for everyone from a technical department to go, especially if
+   they are not all reading the Internet-Drafts and following the
+   Working Group mailing lists.  Many companies have just a few
+   designated meeting attendees who are chosen for their ability to do
+   complete and useful trip reports.  In addition, many companies have
+   internal coordination efforts and a standards strategy.  If a company
+   depends on the Internet for some or all of its business, the strategy
+   should probably cover the IETF, but note that IETF participation is
+   as an _individual_ not a formal representative of their employer.
+
+3.12.4 Academics
+
+   IETF meetings are often excellent places for all kinds of researchers
+   to find out what is happening in the way of soon-to-be-deployed
+   protocols, and networking architecture and infrastructure.
+   Professors and grad students (and sometimes overachieving undergrads)
+   who are doing research in networking or communications can get a
+   wealth of information by following Working Groups in their specific
+   fields of interest.  Wandering into different Working Group meetings
+   can have the same effect as going to symposia and seminars in your
+   department.  Researchers are also, of course, likely to be interested
+   in IRTF activities.
+
+   In addition, the IRTF and ACM co-host the annual Applied Networking
+   Research Workshop (https://irtf.org/anrw/), normally scheduled during
+   the July IETF meeting Registration is required, IETF attendees can
+   attend for free.  The IRTF also hosts the Applied Networking Research
+   Prize (https://irtf.org/anrp/), which includes a cash prize, a travel
+   grant to attend, and a chance to present.  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 the special section below.
+
+3.13 Proceedings
+
+   IETF proceedings are compiled in the weeks and months after each
+   meeting and are available online (https://www.ietf.org/how/meetings/
+   proceedings/).  Be sure to look through a copy at least once; the
+   proceedings are filled with information about IETF that you're not
+   likely to find anywhere else.  For example, you'll copies of every
+   session's slides, links to the video recording, 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 someone and introduce yourself.  Also, don't be afraid to
+   ask questions, especially when it comes to jargon and acronyms.  If
+   someone is presenting an update to their draft, feel free to step up
+   to the mic and ask a clarifying question.  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 done by 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's dismay).
+
+   A side meeting (historically but often inaccurately called a "bar
+   BOF") is an unofficial get-together between WG meetings or in the
+   late evening, during which a lot of work gets done.  These side
+   meetings spring up in many different places around an IETF meeting,
+   such as restaurants, coffee shops, unused hall spaces and the like.
+   You can read more about Birds-of-a Feather sessions (BOFs) in section
+   5.
+
+   The IETF meetings, and the plenary session in particular, are not
+   places for vendors to try to sell their wares.  People can certainly
+   answer questions about their company and its products, but bear in
+   mind that the IETF is not a trade 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, descriptions of online IETF-related
+   information).  Please check with the Secretariat before placing
+   materials on the desk; the Secretariat has the right to remove
+   material that they feel is not appropriate.
+
+3.15 Remote Participation
+
+   People have joined IETF meetings remotely for a long time, but the
+   tools for this have changed a lot over the years.  Currently the IETF
+   uses a browser- based tool known as _MeetEcho_. There is also a text-
+   based discussion forum called _Jabber_. This is integrated into
+   MeetEcho, but there are also stand-alone clients available.  Planned
+   for 2022, the _Zulip_ text will 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 different icons.  All sessions are recorded and can be
+   viewed after the meeting, along with chat logs and meeting minutes.
+   This can be useful to refresh your memory while writing a trip
+   report, or for catching up on what happened when you wanted to be in
+   two WG meetings at once.  It happens; scheduling conflicts are
+   unavoidable.
+
+4 Working Groups
+
+   The vast majority of the IETF's work is done in its many Working
+   Groups; at the time of this writing, there are well over one hundred
+   different WGs.  BCP 25 (https://www.rfc-editor.org/info/bcp25), "IETF
+   Working Group Guidelines and Procedures," is an excellent resource
+   for anyone participating in WG discussions.  The full list of working
+   groups can be found on the datatracker (https://datatracker.ietf.org/
+   wg/).
+
+   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 open to anyone.  Anyone can post to a WG
+   mailing list, although non-subscribers have to have their postings
+   approved first.
+
+   More importantly, each WG has a charter that the WG is supposed to
+   follow.  The charter states the scope of discussion for the Working
+   Group and its goals.  The WG's mailing list and face-to-face meetings
+   are supposed to focus on only what is in 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 large
+   majority 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 there were some attractive but nebulous
+   topics brought up during the drafting of the charter.  The list of
+   all WG charters makes interesting reading for folks who want to know
+   what the different Working Groups are supposed to be doing.  Each WG
+   has its own page on the datatracker.
+
+4.1 Working Group Chairs
+
+   Each Working Group has one or two (or, rarely, three) chairs.  The
+   role of the WG chairs is described in both BCP 11 (https://www.rfc-
+   editor.org/info/bcp11) and BCP 25 (https://www.rfc-editor.org/info/
+   bcp25).
+
+   Chairs have responsibility for the technical and non-technical
+   quality of WG output.  The chair must keep the WG productive, and
+   making progress on its drafts.  Sometimes there is a WG Secretary to
+   help.  Document editors, too, are usually incentivized to make
+   progress on their drafts.  The chair must manage WG discussion, both
+   on the list and by scheduling meetings when appropriate.  Sometimes
+   discussions get stuck on contentious points and the chair may need to
+   steer people toward productive interaction and then declare when
+   rough consensus has been met and the discussion is over.  Sometimes
+   chairs also manage interactions with non-WG participants or the IESG,
+   especially when a WG document approaches publication.  As you can
+   imagine given the mix of secretarial, interpersonal, and technical
+   demands, some Working Group chairs are much better at their 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 much less important in the IETF than they are in most
+   other organizations.  Any decision made at a face-to-face meeting
+   must also gain consensus on the WG mailing list.  This is sometimes
+   phrased as "at the last WG meeting, we decided XXX; if you disagree
+   please 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 decisions made in WG meetings that are later
+   overturned on the mailing list, often because someone who couldn't
+   attend the meeting pointed out a serious flaw in the logic used 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 that there is no formal voting.  The general rule on disputed
+   topics is that the Working Group has to come to "rough consensus,"
+   meaning that a very large majority of those who care must agree, and
+   that those in the minority have had a chance to explain why.
+   Generally consensus is determined by _humming_: if you agree with a
+   proposal, you hum when prompted by the chair.  Most hum questions
+   come 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 have enough information to make up your mind.  Newcomers
+   find it quite peculiar, but it works.  It is up to the chair to
+   decide when the Working Group has reached rough 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 acrimonious debates feel that the delays often result
+   in better protocols.  (And, if you think about it, how could you have
+   "voting" in a group that invites all interested individuals to
+   participate, and when it's impossible to count the participants?)  A
+   common definition and practice of humming can be found in RFC 7282:
+   On Consensus and Humming in the IETF (https://www.rfc-
+   editor.org/info/rfc7282).
+
+   A related problem is that some people think that their topic should
+   be discussed in the WG even when the WG chair believes it is outside
+   the scope of the charter.  If the WG agrees, they can work to _re-
+   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.  (Most WG mailing lists continue on after a WG is closed,
+   still discussing the same topics as the Working Group did.)  In the
+   IETF, it is a mark of success that the WG closes up because it
+   fulfilled its charter.  This is one of the aspects of the IETF that
+   newcomers who have experience with other standards bodies have a hard
+   time understanding.
+
+4.3 Working Group Documents
+
+   There is an official distinction between WG I-Ds and individual I-Ds.
+   A WG will have to review an individual draft before deciding if it
+   should be adopted by the WG.  The WG chairs appoint who will be the
+   authors or editors of the I-Ds; often those who wrote the initial
+   draft continue work on behalf of the WG.  Procedures for Internet-
+   Drafts are covered in much more detail later in this document.
+
+   For Working Group documents, the document editor serves at the
+   pleasure of the WG Chair.  There is often more than one editor for
+   Working Group documents, particularly for complex documents.  The
+   document editor is responsible for ensuring that the contents of the
+   document accurately reflects Working Group decisions; when a document
+   editor does not follow the WG consensus, the WG Chairs will either be
+   more forceful about getting changes that match the consensus or
+   replace the document editor with someone more responsive to the WG.
+   As a Working Group document is progressing, participants suggest
+   changes on the Working Group's mail list (or online if the document
+   is maintained somewhere accessible); the editors are expected to
+   follow the discussion and make changes when there is consensus.
+
+   Sometimes a Working Group will consider several alternatives before
+   selecting a particular Internet-Draft as a Working Group document.  A
+   Working Group will often take ideas from several of the alternatives
+   to create a single Working Group document; in such a case, the chair
+   determines who will be listed as authors on the title page and who
+   will be acknowledged as contributors in the body of the document.
+
+   When a WG document is ready to progress beyond the WG, the WG Chairs
+   will assign a "shepherd" to take over the final process.  The role of
+   the document shepherd is described in RFC 4858: Document Shepherding
+   from Working Group Last Call to Publication (https://www.rfc-
+   editor.org/info/rfc4858).  The chair, who knows the history of the
+   draft within the WG, often does the shepherd write-up.
+
+4.4 Preparing for Working Group Meetings
+
+   The most important thing that *everyone* should do before coming to a
+   face-to-face meeting is to read the Internet-Drafts and RFCs ahead of
+   time.  WG meetings are explicitly not for education: they are for
+   developing the group's documents 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 say anything in the meeting, you should
+   read, or at least skim, the group's documents 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 in advance.  If you want something discussed at the meeting, be
+   sure to let the chair know about it.  The agendas for all the WG
+   meetings are available in advance on the datatracker, and links to
+   will be found on every full meeting agenda.  Unfortunately, some WG
+   chairs are lax (if not totally negligent) about turning them in.
+
+   The Secretariat only makes the full IETF meeting schedule a few weeks
+   in advance, and the schedule often changes as little as a week before
+   the first day.  If you are only coming for one WG meeting, you may
+   have a hard time booking your flight with such little notice,
+   particularly if the Working Group's meeting changes schedule.  Be
+   sure to keep track of the current agenda so you can schedule flights
+   and hotels.  But, when it comes down to it, you probably shouldn't be
+   coming for just one WG meeting.  It's likely that your knowledge
+   could be valuable in a few WGs, assuming that you've read the I-Ds
+   and RFCs for those groups.  Work in the IETF is often reciprocal,
+   contribute positively to others work and you are more likely to
+   receive comments and feedback on your work.
+
+   If you are on the agenda at a face-to-face meeting, you should
+   prepare a few slides and mail them to the chair before the meeting.
+   Don't come with a tutorial; people are supposed to read the I-Ds in
+   advance.  Projectors for laptop-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 this kind of corporate advertising (except for the
+   meeting sponsor in the plenary presentation), and most presenters
+   don't even put their logo on their opening slide.  The IETF is about
+   technical content, not company boosterism.  Slides are often plain
+   black and white for legibility, with color used only when it really
+   adds clarity.  Again, the content is the most important part of the
+   slides, not how it's presented.
+
+   One thing you might find helpful, and possibly even entertaining,
+   during Working Group sessions is to follow the running commentary on
+   the Jabber room associated with that Working Group.  Jabber is a
+   free, streaming XML technology mainly used for instant messaging.
+   You can find pointers to Jabber clients for many platforms at
+   (https://xmpp.org/xmpp-software/clients).  The Jabber chatrooms have
+   the 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 used by active Working Group participants
+   during protocol development.
+
+4.5 Working Group Mailing Lists
+
+   As we mentioned earlier, the IETF announcement and discussion mailing
+   lists are the central mailing lists for IETF activities.  However,
+   there are many other mailing lists related to IETF work.  For
+   example, every Working Group has its own discussion list.  In
+   addition, there are some long-term technical debates that have been
+   moved off of the IETF list onto lists created specifically for those
+   topics.  It is highly recommended that you follow the discussions on
+   the mailing lists of the Working Groups that you wish to attend.  The
+   more work that is done on 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's primary areas of
+   interest in order to broaden one's perspective).
+
+   The mailing lists also provide a forum for those who wish to follow,
+   or contribute 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 a discussion.
+
+   Every WG has a dedicated page on the datatracker site, and the
+   "About" tab will point to mailing list subscription and archives.
+
+4.6 Interim Working Group Meetings
+
+   Working Groups sometimes hold interim meetings between IETFs.
+   Interim meetings aren't a substitute for IETF meetings, however -- a
+   group can't decide to skip a meeting in a location they're not fond
+   of and meet in Cancun (or even someplace mundane) three weeks later,
+   for example.  Interim meetings need to be announced at least one
+   month in advance.  Location and timing need to allow fair access for
+   all participants.  Like regular IETF meetings, someone needs to take
+   notes and the group needs to take attendance.  Decisions tentatively
+   made during an interim WG meeting must still be confirmed on the
+   mailing list.  Interim meetings are subject 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 Group meetings, as well as reporting the results of the
+   meetings.  The purpose of these rules is to make interim meetings
+   accessible to as many Working Group members as possible 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 able to be chair.  In order to get those things, you need to get
+   people interested so that they can help focus the charter and
+   convince an Area Director that the project is worthwhile.  A face-to-
+   face meeting is useful for this.  In fact, very few WGs get started
+   without an initial meeting.
+
+   A _Birds of a Feather_ (BOF) meeting has to be approved by the Area
+   Director in the relevant area, in consultation with the IESG and the
+   IAB, before it can be scheduled.  If you think you need a new WG,
+   approach an AD with your proposal and see what they think.  You will
+   have to write some informative background 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 the meantime.
+
+   BOF meetings have a very different tone than do WG meetings.  The
+   purpose of a BOF is to make sure that a good charter with good
+   milestones can be created, that there are enough people willing to do
+   the work needed in order to create standards, and that any standards
+   would get adoption.  Often a self-selected group of key people will
+   get together after the BOF to refine 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, and sometimes 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 submitted documents, and come to a decision about the next
+   steps: possibilities include create 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 the
+   discussion is more limited and focused.  On the other hand, a draft
+   might tend 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 eventual Working 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 a brief note on other RFC streams, see above.
+
+   If you're a new IETF participant and are looking for a particular RFC
+   or Internet-Draft, you can use the IETF _Datatracker_. This website,
+   https://datatracker.ietf.org/ (https://datatracker.ietf.org/), has a
+   text search capability (including content, keywords, author, and so
+   on), and the search results point to the document status, page count,
+   and other useful information.  A little-known hint is that
+   _dt.ietf.org_ is an abbreviation (a DNS CNAME entry) for the longer
+   "datatracker.ietf.org" hostname.
+
+   Most RFCs in the IETF stream follow the same process, and the
+   sections below discuss the process and some of the issues.  Note that
+   there are other ways to get an RFC published
+   (https://www.ietf.org/about/participate/get-
+   started/#officialdocuments), particularly if it is not intended for
+   the standards track.  For the sake of brevity, we will not mention
+   those 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-Draft yourself, the I-D Authors website
+   (https://authors.ietf.org) has a lot of information and resources,
+   including pointers to online tools that can help.
+
+6.1 The Overall Process
+
+   The very first step is to have a draft document.  Internet-Drafts
+   should follow a specific format, and are required to have particular
+   sections.  This will be discussed more below.
+
+   RFCs are generally written by a Working Group.  If an appropriate WG
+   doesn't seem to exist, then the BOF or Dispatch process 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 be _adopted_. To do
+   this, you submit your individual draft to the datatracker.  It should
+   start with draft-YOURNAME-brief-subject where _YOURNAME_ is your
+   name.  Send a note to the WG mailing list, with an introduction to
+   the draft, and why you think it is appropriate.  After any
+   discussion, the WG Chair will issue a _call for adoption_. If
+   consensus is to adopt the draft, you will be asked to submit it with
+   the name draft-ietf-WGNAME-brief-subject; you can probably guess what
+   _WGNAME_ should be.
+
+   Note that as part of submitting an Internet Draft according to the
+   rules, you grant the IETF certain rights.  These rights give the IETF
+   the ability to reliably build upon the work you have brought forward.
+   These rights are held by the IETF Trust.  BCP 78 (https://www.rfc-
+   editor.org/rfc/rfc5378.html) explains 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
+   "change control."  This means the WG, can make any changes to the
+   document, the one you 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 more details on this below.
+
+   The WG now "works on" the document.  This will be a combination of
+   mailing list discussion, perhaps agenda time at a meeting, and
+   publishing updated drafts.  (Every draft ends with _-NN_ where the
+   digits indicate the draft number.)
+
+   At some point, the document will seem finished.  The WG Chair will
+   put the document in _WG Last Call_ (WGLC) which gives the members of
+   the WG a chance for last-minute changes.  It can be frustrating to
+   get a bunch of changes after 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 and the overall IETF reviews the draft, as mentioned
+   above.  The purpose of IETF Last Call is to get community-wide
+   discussion on documents before the IESG considers them.  Note the
+   word _discussion_ here.  It is generally considered bad form to send
+   IETF Last Call comments on documents that you have not read, or to
+   send comments but not be prepared to discuss your views.  The IETF
+   Last Call is not a vote.  Having said that, IETF Last Call comments
+   that come from people who have just read the document for the first
+   time can expose issues that IETF and WG regulars may have completely
+   missed, which is why the discussion is open to everyone.
+
+   Finally, the draft is given to the RFC Production Center (RPC), and
+   prepared for publication.  There might be other changes required,
+   including reviews by IANA for registrations and the like.  The most
+   common item you'll hear about this is _AUTH48_ state, which means the
+   document is in the final stages of copy-editing by the RPC and you.
+   The publication process can take weeks, but be patient, and you'll
+   eventually see an email announcement saying that your brand-new RFC
+   has been published.  Congratulations!
+
+   A much more complete explanation of these steps is contained in BCP 9
+   (https://www.rfc-editor.org/info/bcp9).  This set of documents goes
+   into great detail on a topic that is very often misunderstood, even
+   by seasoned IETF participants: different types of 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 an Internet-Draft, it is required that the _boilerplate_, the
+   common text that appears in every draft, has a notice that says the
+   IETF, _and the document authors_ own the copyright.  This means that
+   while the IETF can do what it wants with the document, within
+   limitations so can you.  You cannot, for example, claim this is an
+   IETF standard, nor use the IETF trademarks.
+
+   Incidentally, the change control on Internet standards doesn't end
+   when the RFC is published.  Things can be changed later for a number
+   of reasons, such as to solve a newly-discovered problem or address
+   new use-cases.  These later changes are also under the control of the
+   IETF, not the editors of the standards document.
+
+   The second issue is patents.  The goal of the IETF is to have its
+   standards widely used and validated by the marketplace.  If creating
+   a product that uses a standard requires getting a license for a
+   patent, people are less likely to implement the standard.  Not
+   surprisingly, then, the general rule has been "use good non-patented
+   technology where possible."
+
+   Of course, this isn't always possible.  Sometimes patents appear
+   after a standard 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't a non-patented equivalent, and generally
+   the IETF tries to avoid it.
+
+   Sometimes the patent holder is generous and promises to give all
+   implementors of a standard a royalty-free license to the patent,
+   thereby making it almost as 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 the specification.
+
+   The official rules for all intellectual property rights (IPR) in IETF
+   documents, not just patents but also code samples and the like, are
+   covered in BCP 78 (https://www.rfc-editor.org/info/bcp78) and BCP 79
+   (https://www.rfc-editor.org/info/bcp79).
+
+   If you are writing an Internet-Draft and you know of a patent that
+   applies to the technology you're writing about, don't list the patent
+   in the document.  Instead, consult the IPR disclosures
+   (https://datatracker.ietf.org/ipr/about/) page.  If you still have
+   issues, consult with the WG Chair or the responsible AD.
+   Intellectual property rights aren't mentioned in RFCs because RFCs
+   never change after they are published, while knowledge of IPR can
+   change at any time.  Therefore, an IPR list in an RFC could be
+   incomplete and mislead the reader.  BCP 79 (https://www.rfc-
+   editor.org/info/bcp79) provides specific text that should be added to
+   RFCs where the author knows 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.  This includes a couple of sections
+   detailed below.  A draft may also have more information, such as an
+   incremental list of changes from previous versions of the draft, or
+   pointers to online locations for raising issues and suggesting
+   changes.
+
+   For the past several years, the official canonical source of RFCs as
+   RFC 7991: The "xml2rfc" Version 3 Vocabulary (https://www.rfc-
+   editor.org/info/rfc7991).  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 the publication process).  A recent trend is the
+   increasing use of markdown, and hosting I-Ds on GitHub to attract a
+   wider audience of Internet-savvy users.  Some information on this can
+   be found at RFC 8874: Working Group GitHub Usage Guidance
+   (https://www.rfc-editor.org/info/rfc8874).
+
+   The IETF is setting up a new site, https://authors.ietf.org
+   (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 great deal of useful content.
+   You should feel free to use the site, and offer feedback.
+
+   Outside of the formatting decision, the most important document you
+   can read is Guidelines to Authors of Internet-Drafts
+   (https://www.ietf.org/how/ids/guidelines).  That document explains
+   the naming conventions, formatting requirements, required content,
+   and details of how to submit (also called _post_) your draft.
+
+6.3.1 Internet-Draft Language
+
+   It is common for Internet-Drafts that revise existing RFCs to have
+   draft names with "bis" in them, meaning "again" or "twice."  For
+   example, a draft might be called "draft-ietf-uta-rfc6125bis" meaning
+   that this is intended to be a revision of, and eventual replacement
+   for, RFC6125.
+
+   Writing clear specifications can be a bit of an art, particularly for
+   people who don't have English as their native language.  You can keep
+   the specification very short, with just a list of requirements, but
+   that tends to cause implementors to take too much leeway.  If you
+   instead make the specification very wordy with lots of suggestions,
+   implementors tend to miss the requirements (and often disagree with
+   your suggestions anyway).  An optimal specification is somewhere in
+   between.
+
+   One way to make it more likely that developers will create
+   interoperable implementations of standards is to be clear about
+   what's being mandated in a specification.  Over time, the IETF has
+   realized that defining a few words with specific meanings helps a
+   great deal.  BCP 14 (https://www.rfc-editor.org/info/bcp14) defines
+   about a dozen keywords that can be used to clarify what are
+   requirements, as compared to what is purely informative.  It defines
+   the meaning of words like _MUST_ and points out that it has to appear
+   in all uppercase to its special meaning.
+
+   It is not uncommon for feedback on standards-track I-Ds to question
+   the particular uses of what is called "2119 language."  For example,
+   "The document says MAY but doesn't explain why not; should it be a
+   MUST?"
+
+6.3.2 About References
+
+   One aspect of writing IETF standards that trips up many newcomers is
+   the rule about how to make _normative references_ to non-IETF
+   documents or to other RFCs in a standard.  A normative reference is a
+   reference to a document that must be followed in order to implement
+   the standard.  A non-normative reference (sometimes called an
+   _informative reference_) is one that is helpful to an implementor but
+   not strictly needed to implement it.
+
+   An IETF standard may make a normative reference to any other
+   standards-track RFC that is at the same standards level or higher, or
+   to any "open standard" that has been developed outside the IETF.  The
+   "same level or higher" rule means that before a standard can move
+   from Proposed to Internet Standard, all of the RFCs that appear as a
+   normative reference must also be an Internet Standard.  This rule
+   gives implementors assurance that everything in an Internet standard
+   is quite stable, even the things referenced outside the standard.
+   This rule, and its exceptions, is described in BCP 97
+   (https://www.rfc-editor.org/info/bcp97).
+
+   There is no hard-and-fast rule about what is an "open standard", but
+   generally this means a stable standard that was made by a generally-
+   recognized SDO, and that anyone can get a copy of, although not
+   necessarily for free.  If the external standard changes, you have to
+   reference the particular instantiation of that standard in your
+   specification, as with a designation of the date of the standard.
+   Some external standards bodies don't make old standards available,
+   which is a problem 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 an IETF standard.
+
+6.3.3 About Required Content
+
+   Every draft is required to have some content.  Some of this is
+   boilerplate text about copyright, "2119 keyword," and so on.  The
+   document formatting tools will generate this for you automatically if
+   you use the right keyword.  In addition, there are special sections
+   that might be required for your draft, and you (and the WG) will have
+   to write them.
+
+   Many IETF standards have extension points, such as unassigned fields
+   in a message header, or for something like email or HTTP, an actual
+   message header.  As mentioned above, IANA maintains online registries
+   for these.  Because of the large and diverse kinds of registries that
+   standards require, IANA needs to have specific information about how
+   to register parameters, what not to register, who (if anyone)
+   approves any registration requests, and so on.
+
+   Anyone writing a draft that needs one or more registries, or adds
+   values to existing registries must have an "IANA Considerations"
+   section.  Authors should read BCP 26 (https://www.rfc-
+   editor.org/info/bcp26), "Guidelines for Writing an IANA
+   Considerations Section in RFCs," which describes how to properly ask
+   for IANA to make the changes requested in their draft.  If there are
+   no considerations, it is a good idea to have the section and
+   explicitly say "This document has no IANA requests."
+
+   Every draft must have a "Security Considerations" section.  This
+   describes possible threats or attacks, known vulnerabilities,
+   information that could be exposed, and so on.  It should also
+   describe any strategies or mechanisms to mitigate them.  When the
+   security directorate (SECDIR) reviews your draft, this section will
+   be one of their major focuses.  Don't gloss over the section, or say
+   things like "use TLS to get security" without explaining how the
+   protocol uses TLS and what it provides.  See BCP 72 (https://www.rfc-
+   editor.org/info/bcp72), "Guidelines for Writing RFC Text on Security
+   Considerations", for more information on writing good security
+   considerations sections.
+
+   Also, a draft might have a "Privacy Considerations" section.  An
+   Informational RFC, RFC 6973: Privacy Considerations for Internet
+   Protocols (https://www.rfc-editor.org/info/rfc6973), written by the
+   IAB, is intended to raise the general awareness of privacy on the
+   Internet.  It also provides advice for when a draft should have an
+   explicit privacy section.
+
+   Some drafts benefit from having an "Implementation Status" section,
+   as explained by BCP 205: Improving Awareness of Running Code: The
+   Implementation Status Section (https://www.rfc-editor.org/info/
+   rfc7942).
+
+   More detail on the required content can be found online
+   (https://authors.ietf.org/en/required-content).
+
+6.4 Standards-Track RFCs
+
+   If the IESG approves the draft to become a standards-track RFC, they
+   ask the RPC to publish it as a _Proposed Standard_.
+
+   Don't be surprised if a particular standard doesn't progress from
+   Proposed Standard to Internet Standard.  To become an Internet
+   Standard, an RFC must have multiple interoperable implementations and
+   the unused features in the Proposed Standard must be removed; there
+   are additional requirements listed in BCP 9 (https://www.rfc-
+   editor.org/info/bcp9).  Most of the protocols in common use are
+   Proposed standards and never move forward.  This may 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 Proposed
+   standard, 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
+   important RFCs are not on the standards track at all.  At the time of
+   writing, there are also categories for Informational, Experimental,
+   Best Current Practice, and Historical for standards that are no
+   longer recommended for use.  The role of Informational RFCs can be
+   confusing, and people sometimes refer to them as "standards," when
+   they are not.
+
+   Experimental RFCs are for specifications that are interesting, but
+   for which it is unclear if there will be widespread deployment, or if
+   they will scale to work after such deployment.  That is, a
+   specification might solve a problem, but there might not be IETF
+   consensus that the problem is worth solving or that the specification
+   is complete enough to address the problem.  Experimental RFCs are
+   also used to get people to experiment with a technology that looks
+   like it might be standards-track material, but for which there are
+   still unanswered questions.
+
+   The IESG has created guidelines
+   (https://www.ietf.org/standards/process/informational-vs-
+   experimental/) that can help choose between Informational and
+   Experimental classification.  This is a short informal read, and if
+   are not sure where your 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
+   various technologies in the Internet, and are also commonly used to
+   document the many parts of the IETF process.  The STD sub-series was
+   created to identify RFCs that do in fact specify Internet standards.
+
+   These are an example of the aphorism that everything in computer
+   science can be solved by a layer of indirection.  For example, a
+   single BCP can refer to one or more RFCs, and the specific RFCs can
+   change such as when a new version of a protocol is published.
+   Likewise, some STDs are actually sets of more than one RFC, and the
+   "standard" designation applies to the whole 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 on them 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 technical issues: never attack the people.
+
+   *Implement:* Write programs that use the current Internet standards.
+   The standards aren't worth much unless they are available to Internet
+   users.  Implement even the "minor" standards, since they will become
+   less minor if they appear in more software.  Report any problems you
+   find with the standards to the appropriate Working Group so that the
+   standard can be clarified in later revisions.  Remember the tenet,
+   "rough consensus and running code," so you can help support the
+   standards you want to become more widespread by creating more running
+   code.  You can help the development of protocols before they become
+   standards by implementing I-Ds (but not doing wide-spread deployment)
+   to ensure that the authors have done a good job.  If you find errors
+   or omissions, offer improvements based on your implementation
+   experience.  A great way to get involved in this is by participating
+   in the Hackathons.
+
+   *Write:* Edit or co-author Internet-Drafts in your area of expertise.
+   Do this for the benefit of the Internet community, not to get your
+   name (or, even worse, your company's name) on a document.  Draft
+   authors receive kinds of technical (and, sadly, sometimes personal)
+   criticism.  Take the technical comments with equanimity and use it to
+   improve your draft in order to produce the 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 a strong preference for IETF standards.  If the IETF
+   standards aren't as good as the proprietary standards, work to make
+   the IETF standards better.  If you're a purchaser, avoid products
+   that use proprietary standards that compete with the 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 is implementing the standard.  Patents have
+   previously caused many serious problems for Internet standards
+   because they prevent some companies from being able to freely
+   implement them.  Fortunately, many companies have generously offered
+   unlimited licenses for particular patents in order to help the IETF
+   standards flourish.  These companies are usually rewarded with
+   positive publicity for the fact that they are not as greedy or short-
+   sighted as other patent-holders.
+
+   *Support:* The IETF has sponsorship opportunities
+   (https://ietf.org/about/donors/) and an endowment
+   (https://www.ietf.org/endowment/donate-ietf-endowment/) which can
+   also take individual-sized donations.  Become a member of ISOC.  Urge
+   any company that has benefited from the Internet to contribute, since
+   this has the greatest financial benefit for the group.  It will, of
+   course, also benefit the Internet as a whole.
+
+8 IETF and the Outside World
+
+   While some IETF participants would like to think otherwise, the IETF
+   does not exist in a standards vacuum.  This section discusses two
+   important groups.
+
+8.1 IETF and Other SDOs
+
+   There are many other standards organizations whose decisions affect
+   the Internet.  Some of them ignored the Internet for a long time and
+   now want to get a piece of the action.  In general, the IETF tries to
+   have cordial relationships with other SDOs.  This isn't always easy,
+   since they usually have different structures and processes than the
+   IETF does, and the IETF is mostly run by volunteers who would
+   probably prefer to write standards rather than meet with
+   representatives from other bodies.  Even so, many SDOs make a great
+   effort to interact well with the IETF despite the obvious cultural
+   differences.
+
+   As stated in BCP 39 (https://www.rfc-editor.org/info/bcp39), the IAB
+   Charter: "Liaisons are kept as informal as possible and must be of
+   demonstrable value in improving the quality of IETF specifications."
+   In practice, the IETF prefers liaisons to take place directly at the
+   WG level, with formal relationships and liaison documents in a backup
+   role.  The best place to check to see whether the IETF has any formal
+   liaison at all is the list of IETF liaisons
+   (https://www.ietf.org/about/liaisons).
+
+   At the time of this writing, the IETF has around two dozen liaisons.
+   Some of these liaison tasks fall to the IESG, whereas others fall to
+   the IAB.  Full details about the processes for dealing with other
+   SDOs can be found in BCP 102 (https://www.rfc-editor.org/info/bcp102)
+   and BCP 103 (https://www.rfc-editor.org/info/bcp103).
+
+8.2 Press Coverage of the IETF
+
+   Given that the IETF is one of the best-known bodies that is helping
+   move the Internet forward, it's natural for the media to cover its
+   actions.  But it can be hard to cover the IETF; a common mistake is
+   reporting an individual's Internet-Draft as something the IETF is
+   working on, or that the IETF has approved 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 have been alerted to the
+   story by a company trying to get publicity for a protocol, or they
+   see the latest "controversy" on social media.
+
+   Reporters who want to find out about "what the IETF is doing" on a
+   particular topic would be well-advised to talk to more than one
+   person who is active on that topic in the IETF, and should probably
+   try to talk to the WG chair in any case.  It's impossible to
+   determine what will happen with a draft by looking at the draft or
+   talking to the draft's author.  Fortunately, all WGs have archives
+   that a reporter can look through for recent indications about what
+   the progress of a draft is; unfortunately, few reporters have the
+   time or inclination to do this kind of research.
+
+   Reporters looking for information about the IETF, or pointers to IETF
+   participants working on a particular topic relevant to the IETF,
+   should send a message to media@ietf.org (mailto:media@ietf.org), and
+   a full page of contacts for a variety of needs is available online
+   (https://www.ietf.org/contact/).  Replies are usually sent within 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 a topic 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:
+
+   *  Gary Scott Malkin
+
+   *  Susan R. Harris
+
+   *  Paul Hoffman
+
+   *  Kathleen Moriarty
+
+   *  Niels ten Oever
+
+   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