Skip to main content

Entities Involved in the IETF Standards Process
RFC 9281

Document Type RFC - Best Current Practice (June 2022)
Obsoletes RFC 2028
Was draft-rsalz-2028bis (individual)
Author Rich Salz
Last updated 2022-06-30
Stream Internet Engineering Task Force (IETF)
Formats
Reviews
OPSDIR Last Call Review Incomplete, due 2022-03-07
Stream WG state (None)
Document shepherd Eliot Lear
IESG IESG state RFC 9281 (Best Current Practice)
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Lars Eggert
Send notices to lear@cisco.com
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions
RFC 9281


Internet Engineering Task Force (IETF)                           R. Salz
Request for Comments: 9281                           Akamai Technologies
BCP: 11                                                        June 2022
Obsoletes: 2028                                                         
Category: Best Current Practice                                         
ISSN: 2070-1721

            Entities Involved in the IETF Standards Process

Abstract

   This document describes the individuals and organizations involved in
   the IETF standards process, as described in BCP 9.  It includes brief
   descriptions of the entities involved and the role they play in the
   standards process.

   The IETF and its structure have undergone many changes since RFC 2028
   was published in 1996.  This document reflects the changed
   organizational structure of the IETF and obsoletes RFC 2028.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   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).  Further information on
   BCPs is available in 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/rfc9281.

Copyright Notice

   Copyright (c) 2022 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
     1.1.  Terminology
     1.2.  Changes since RFC 2028
   2.  Key Individuals in the Process
     2.1.  Document Editor or Author
     2.2.  Working Group Chair
     2.3.  Area Director
   3.  Key Organizations in the Process
     3.1.  Internet Engineering Task Force (IETF)
     3.2.  Working Groups (WGs)
     3.3.  Internet Engineering Steering Group (IESG)
     3.4.  Internet Architecture Board (IAB)
     3.5.  RFC Production Center (RPC)
     3.6.  Internet Assigned Numbers Authority (IANA)
     3.7.  Internet Research Task Force (IRTF)
     3.8.  IETF Trust
     3.9.  IETF Administration LLC (IETF LLC)
     3.10. IETF Secretariat
     3.11. Internet Society (ISOC)
   4.  Security Considerations
   5.  IANA Considerations
   6.  Informative References
   Acknowledgements
   Author's Address

1.  Introduction

   The process used by the IETF community for the standardization of
   protocols and procedures is described in BCP 9 [IETFPROCS].  BCP 9
   defines the stages in the standardization process, the requirements
   for moving a document between stages, and the types of documents used
   during this process.  This document identifies some of the key
   individual roles and organizations in that process.

1.1.  Terminology

   This document refers to individual roles in the singular, such as "a
   document editor."  In reality, many roles are filled by more than one
   person at the same time.  For clarity, this document does not use
   phrases like "chair (or co-chair)."

1.2.  Changes since RFC 2028

   The following changes have been made, in no particular order:

   *  Added the role of responsible area director (AD) and reordered
      Section 2 to follow the typical workflow.

   *  Added the IETF Administration LLC and the IETF Trust to Section 3.

   *  Changed "RFC Editor" to "RFC Production Center" to reflect the
      changes made by [RFCEDMODEL].

   *  Added the Terminology and Acknowledgements sections.

   *  Cleaned up some wording throughout the document.

2.  Key Individuals in the Process

   This section describes the individual roles involved in the process.
   It attempts to list the roles in the order in which they are involved
   in the process, without otherwise expressing significance.

2.1.  Document Editor or Author

   Most working groups (WGs) focus their efforts on one or more
   documents that capture their work results.  The WG chair designates
   one or more people to serve as the editor(s) for a particular
   document.  The editor is responsible for ensuring that the contents
   of the document accurately reflect the decisions that have been made
   by the WG.

   When a document is composed and edited mainly by one or more
   individuals, they may be referred to as "document authors".  The
   distinction is not significant for the standards process.  This
   document uses the term "document editor".

   When a document editor is a chair of the same WG, another chair
   should manage the process around the document.  If another chair is
   not available, the WG and AD must monitor the process especially
   carefully to ensure that the resulting documents accurately reflect
   the consensus of the WG and that all processes are followed.  This is
   the collective obligation of all parties involved in the document.

2.2.  Working Group Chair

   Each WG is headed by a chair who has the responsibility for
   facilitating the group's activities, presiding over the group's
   meetings, and ensuring that the commitments of the group with respect
   to its role in the Internet standards process are met.  In
   particular, the WG chair is the formal point of contact between the
   WG and the Internet Engineering Steering Group (IESG), via the AD of
   the area to which the WG belongs.

   The details on the selection and responsibilities of a WG chair can
   be found in [WGPROCS].

2.3.  Area Director

   Each WG is assigned a single responsible area director (AD).  The AD
   can assist the WG chair in assessing consensus and executing process.
   The AD also reviews documents after the WG has approved them, and
   when satisfied, the AD coordinates the IESG review and IETF Last Call
   of the document.

   An AD can also sponsor an Internet-Draft directly, but this is not
   very common.  When this is done, a WG is not involved.

   Except for the General Area, IETF areas traditionally have multiple
   ADs.

3.  Key Organizations in the Process

   The following organizations and organizational roles are involved in
   the Internet standards process.

3.1.  Internet Engineering Task Force (IETF)

   The IETF is an open international community of network designers,
   operators, implementors, researchers, and other interested parties
   who are concerned with the evolution of the Internet architecture and
   the smooth operation of the Internet.  It is the principal body
   engaged in the development of new Internet Standard specifications
   and related documents.

3.2.  Working Groups (WGs)

   The technical work of the IETF is done in its WGs, which are
   organized by topics into several areas (https://www.ietf.org/topics/
   areas/), each under the coordination of an AD.  WGs typically have a
   narrow focus and a lifetime bounded by completion of specific tasks
   as defined in their charter and milestones.  Some WGs are long-lived
   and intended to conduct ongoing maintenance on IETF protocol(s).
   There are also "dispatch" WGs that assess where new work in the IETF
   should be done but do not directly produce standards.

   For all purposes relevant to the Internet Standards development
   process, membership in the IETF and its WGs is defined to be
   established solely and entirely by individuals who participate in
   IETF and WG activities.  These individuals do not formally represent
   any organizations they may be affiliated with, although affiliations
   are often used for identification.

   Anyone with the time and interest to do so is entitled and urged to
   participate actively in one or more WGs and to attend IETF meetings,
   which are usually held three times a year [MEETINGS].  A WG may also
   schedule interim meetings (virtual, in-person, or hybrid).  These are
   scheduled and announced to the entire WG.  Active WG participation is
   possible without attending any in-person meetings.

   Participants in the IETF and its WGs must disclose any relevant
   current or pending intellectual property rights that are reasonably
   and personally known to the participant if they participate in
   discussions about a specific technology.  The full intellectual
   property policy is defined in [IPRRIGHTS1] and [IPRRIGHTS2].

   New WGs are established by the IESG and almost always have a specific
   and explicit charter.  The charter can be modified as the WG
   progresses.  The guidelines and procedures for the formation and
   operation of WGs are described in detail in [WGPROCS].

   A WG is managed by a WG chair, as described in Section 2.2.
   Documents produced by the group have an editor, as described in
   Section 2.1.  Further details of WG operation can be found in
   [WGPROCS].

   WGs ideally display a spirit of cooperation as well as a high degree
   of technical maturity; IETF participants recognize that the greatest
   benefit for all members of the Internet community results from
   cooperative development of technically excellent protocols and
   services.

3.3.  Internet Engineering Steering Group (IESG)

   The IESG is responsible for the management of the IETF technical
   activities.  It administers the Internet Standards process according
   to the rules and procedures defined in [IETFPROCS].  The IESG is
   responsible for the actions associated with the progression of
   documents along the IETF Stream, including the initial approval of
   new WGs, any subsequent rechartering, and the final approval of
   documents.  The IESG is composed of the ADs and the IETF Chair.  The
   IETF Chair also chairs the IESG and is the AD for the General Area.
   The Chair of the Internet Architecture Board (IAB) is an ex officio
   member of the IESG.  Various other bodies have liaisons with the
   IESG; the full list can be found at
   <https://www.ietf.org/about/groups/iesg/members/>.

   All members of the IESG are nominated by a Nominations Committee
   (colloquially, "NomCom") and are confirmed by the IAB.  See [NOMCOM]
   for a detailed description of the NomCom procedures.  Other matters
   concerning the organization and operation of the NomCom are described
   in the IESG Charter [IESG].

3.4.  Internet Architecture Board (IAB)

   The IAB provides oversight of the architecture of the Internet and
   its protocols.  The IAB approves IESG candidates put forward by the
   NomCom.  It also reviews all proposed IETF WG charters.

   The IAB provides oversight of the standards process and serves as an
   appeal board for related complaints about improper execution
   [IETFPROCS].  In general, it acts as a source of advice about
   technical, architectural, procedural, and policy matters pertaining
   to the Internet and its enabling technologies.

   The members of the IAB are nominated by the NomCom and are confirmed
   by the Board of the Internet Society (ISOC).  The IETF Chair is also
   a member of the IAB, and the Chair of the Internet Research Task
   Force (IRTF) is an ex officio member.  Other matters concerning the
   IAB's organization and operation are described in the IAB Charter
   [IAB].

3.5.  RFC Production Center (RPC)

   Editorial preparation and publication of RFCs are handled by the RFC
   Production Center (RPC).  RFC policy is defined by the RFC Series
   Working Group (RSWG), an open group (similar to IETF WGs), and
   approved by the RFC Series Advisory Board (RSAB), which has appointed
   members.  The RFC Series Consulting Editor (RSCE) is a position
   funded by the IETF Administration LLC, with responsibilities defined
   in [RFCEDMODEL].

   Full details on the roles and responsibilities of the RPC are
   specified in [RFCEDMODEL], in particular Section 4.

3.6.  Internet Assigned Numbers Authority (IANA)

   Many protocol specifications include parameters that must be uniquely
   assigned.  Examples of this include port numbers, option identifiers
   within a protocol, and so on.  The Internet Assigned Numbers
   Authority (IANA) is responsible for assigning values to these
   protocol parameters and maintaining parameter registries online
   (https://www.iana.org/protocols).  Assignments are coordinated by
   writing an "IANA Considerations" section for a given document, as
   described in [IANADOCS].  The IETF's relationship with IANA is
   defined by formal agreements, including [IANAMOU].

   IANA is also responsible for operating and maintaining several
   aspects of the DNS (https://www.iana.org/domains) and coordinating of
   IP address assignments (https://www.iana.org/numbers).

3.7.  Internet Research Task Force (IRTF)

   The IRTF focuses on longer-term research issues related to the
   Internet as a parallel organization to the IETF, which focuses on the
   shorter-term issues of engineering, operations, and specification of
   standards.

   The IRTF consists of a number of research groups (RGs) chartered to
   research various aspects related to the broader Internet.  The
   products of these RGs are typically research results that are often
   published in scholarly conferences and journals, but they can also be
   published as RFCs on the IRTF Stream.  RGs also sometimes develop
   experimental protocols or technologies, some of which may be suitable
   for possible standardization in IETF.  Similarly, IETF WGs sometimes
   ask RGs for advice or other input.  However, contributions from RGs
   generally carry no more weight in the IETF than other community input
   and go through the same standards-setting process as any other
   proposal.

   The IRTF is managed by the IRTF Chair in consultation with the
   Internet Research Steering Group (IRSG).  The IRSG membership
   includes the IRTF Chair, the chairs of the various RGs, and possibly
   other individuals ("members at large") from the community.  Details
   of the organization and operation of the IRTF, the ISRG, and its RGs
   may be found in [IRTF], [IABIRTF], [IRTFPRIMER], and [IRTFCHAIR].

3.8.  IETF Trust

   The IETF Trust is the legal owner of intellectual property for the
   IETF, IRTF, and IAB.  This includes their trademarks, the copyrights
   to RFCs and to works of the IETF such as the IETF website, and
   copyright licenses for IETF contributions including Internet-Drafts.
   The principles for the copyright licenses granted to and from the
   Trust are described in [IPRRIGHTS1] and [COPYRIGHT], and the licenses
   themselves are in the Trust Legal Provisions
   (https://trustee.ietf.org/documents/trust-legal-provisions/).

   The Trust also currently owns IANA's domain names and trademarks
   through an agreement with IANA.

   The Trustees that govern the Trust are selected from the IETF
   community, as described in [TRUSTEES] and the rationale given in
   [TRUSTRAT].

3.9.  IETF Administration LLC (IETF LLC)

   The IETF Administration Limited Liability Company (colloquially, the
   "IETF LLC") provides the corporate legal home for the IETF, the IAB,
   and the IRTF.

   The IETF LLC is responsible for supporting the ongoing operations of
   the IETF, managing its finances and budget, and raising money.  It
   regularly reports to the community.  The IETF LLC is the legal entity
   that signs contracts for the IETF Secretariat, meeting hotels, tools
   development contractors, among many others.  The IETF LLC also
   responds to legal requests; these are often subpoenas in patent
   lawsuits.

   Selection of the IETF LLC Board of Directors is defined in [NOMCOM].

   The IETF Executive Director handles the IETF's daily tasks and
   management and is overseen by the IETF LLC Board of Directors.

   Section 6 of [ISOCIETF] describes the legal relationship between the
   IETF LLC and the Internet Society.

3.10.  IETF Secretariat

   The administrative functions necessary to support the activities of
   the IETF and its various related boards and organizations are
   performed by a Secretariat contracted by the IETF LLC.  The IETF
   Secretariat handles much of the logistics of running the in-person
   meetings and is responsible for maintaining the formal public record
   of the Internet standards process [IETFPROCS].

3.11.  Internet Society (ISOC)

   ISOC plays an important role in the standards process.  In addition
   to being the legal entity that hosts the IETF LLC, ISOC appoints the
   NomCom Chair, confirms IAB candidates selected by the NomCom, and
   acts as the final authority in the appeals process.  This is
   described in [ISOCIETF].

   The way in which the ISOC leadership is selected and other matters
   concerning the operation of the Internet Society are described in
   [ISOC].

4.  Security Considerations

   This document introduces no new security considerations.

5.  IANA Considerations

   This document has no IANA actions.

6.  Informative References

   [COPYRIGHT]
              Halpern, J., Ed., "Advice to the Trustees of the IETF
              Trust on Rights to Be Granted in IETF Documents",
              RFC 8721, DOI 10.17487/RFC8721, February 2020,
              <https://www.rfc-editor.org/info/rfc8721>.

   [IAB]      Internet Architecture Board and B. Carpenter, Ed.,
              "Charter of the Internet Architecture Board (IAB)",
              BCP 39, RFC 2850, May 2000.

              <https://www.rfc-editor.org/info/bcp39>

   [IABIRTF]  Floyd, S., Ed., Paxson, V., Ed., Falk, A., Ed., and IAB,
              "IAB Thoughts on the Role of the Internet Research Task
              Force (IRTF)", RFC 4440, DOI 10.17487/RFC4440, March 2006,
              <https://www.rfc-editor.org/info/rfc4440>.

   [IANADOCS] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, June 2017.

              <https://www.rfc-editor.org/info/bcp26>

   [IANAMOU]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860,
              DOI 10.17487/RFC2860, June 2000,
              <https://www.rfc-editor.org/info/rfc2860>.

   [IESG]     Alvestrand, H., "An IESG charter", RFC 3710,
              DOI 10.17487/RFC3710, February 2004,
              <https://www.rfc-editor.org/info/rfc3710>.

   [IETFPROCS]
              Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

              Dusseault, L. and R. Sparks, "Guidance on Interoperation
              and Implementation Reports for Advancement to Draft
              Standard", BCP 9, RFC 5657, September 2009.

              Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
              October 2011.

              Resnick, P., "Retirement of the "Internet Official
              Protocol Standards" Summary Document", BCP 9, RFC 7100,
              December 2013.

              Kolkman, O., Bradner, S., and S. Turner, "Characterization
              of Proposed Standards", BCP 9, RFC 7127, January 2014.

              Dawkins, S., "Increasing the Number of Area Directors in
              an IETF Area", BCP 9, RFC 7475, March 2015.

              Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream
              Documents Require IETF Rough Consensus", BCP 9, RFC 8789,
              June 2020.

              <https://www.rfc-editor.org/info/bcp9>

   [IPRRIGHTS1]
              Bradner, S., Ed. and J. Contreras, Ed., "Rights
              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
              November 2008.

              <https://www.rfc-editor.org/info/bcp78>

   [IPRRIGHTS2]
              Bradner, S. and J. Contreras, "Intellectual Property
              Rights in IETF Technology", BCP 79, RFC 8179, May 2017.

              <https://www.rfc-editor.org/info/bcp79>

   [IRTF]     Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014,
              October 1996, <https://www.rfc-editor.org/info/rfc2014>.

   [IRTFCHAIR]
              Eggert, L., "The Role of the IRTF Chair", RFC 7827,
              DOI 10.17487/RFC7827, March 2016,
              <https://www.rfc-editor.org/info/rfc7827>.

   [IRTFPRIMER]
              Dawkins, S., Ed., "An IRTF Primer for IETF Participants",
              RFC 7418, DOI 10.17487/RFC7418, December 2014,
              <https://www.rfc-editor.org/info/rfc7418>.

   [ISOC]     Internet Society, "Amended and restated By-Laws of the
              Internet Society", May 2021,
              <https://www.internetsociety.org/about-internet-society/
              governance-policies/by-laws/>.

   [ISOCIETF] Camarillo, G. and J. Livingood, "The IETF-ISOC
              Relationship", RFC 8712, DOI 10.17487/RFC8712, February
              2020, <https://www.rfc-editor.org/info/rfc8712>.

   [MEETINGS] Krishnan, S., "High-Level Guidance for the Meeting Policy
              of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719,
              February 2020, <https://www.rfc-editor.org/info/rfc8719>.

   [NOMCOM]   Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
              Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
              Confirmation, and Recall Process: Operation of the IETF
              Nominating and Recall Committees", BCP 10, RFC 8713,
              February 2020.

              Leiba, B., "Eligibility for the 2020-2021 Nominating
              Committee", BCP 10, RFC 8788, May 2020.

              <https://www.rfc-editor.org/info/bcp10>

   [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
              the IETF Standards Process", BCP 11, RFC 2028,
              DOI 10.17487/RFC2028, October 1996,
              <https://www.rfc-editor.org/info/rfc2028>.

   [RFCEDMODEL]
              Saint-Andre, P., Ed., "RFC Editor Model (Version 3)",
              RFC 9280, DOI 10.17487/RFC9280, June 2022,
              <https://www.rfc-editor.org/info/rfc9280>.

   [TRUSTEES] Arkko, J. and T. Hardie, "Update to the Process for
              Selection of Trustees for the IETF Trust", BCP 101,
              RFC 8714, DOI 10.17487/RFC8714, February 2020,
              <https://www.rfc-editor.org/info/rfc8714>.

   [TRUSTRAT] Arkko, J., "IETF Administrative Support Activity 2.0:
              Update to the Process for Selection of Trustees for the
              IETF Trust", RFC 8715, DOI 10.17487/RFC8715, February
              2020, <https://www.rfc-editor.org/info/rfc8715>.

   [WGPROCS]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

              Wasserman, M., "Updates to RFC 2418 Regarding the
              Management of IETF Mailing Lists", BCP 25, RFC 3934,
              October 2004.

              Resnick, P. and A. Farrel, "IETF Anti-Harassment
              Procedures", BCP 25, RFC 7776, March 2016.

              Resnick, P. and A. Farrel, "Update to the IETF Anti-
              Harassment Procedures for the Replacement of the IETF
              Administrative Oversight Committee (IAOC) with the IETF
              Administration LLC", BCP 25, RFC 8716, February 2020.

              <https://www.rfc-editor.org/info/bcp25>

Acknowledgements

   We are grateful to the authors of [RFC2028] -- Richard Hovey and
   Scott Bradner.

   Barry Leiba, Colin Perkins, Eric Auerswald, John Levine, and Lars
   Eggert provided useful feedback and corrections to this document.

Author's Address

   Rich Salz
   Akamai Technologies
   Email: rsalz@akamai.com