From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9281.txt | 556 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 556 insertions(+) create mode 100644 doc/rfc/rfc9281.txt (limited to 'doc/rfc/rfc9281.txt') diff --git a/doc/rfc/rfc9281.txt b/doc/rfc/rfc9281.txt new file mode 100644 index 0000000..2b2af16 --- /dev/null +++ b/doc/rfc/rfc9281.txt @@ -0,0 +1,556 @@ + + + + +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 + . + + 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, + . + + [IAB] Internet Architecture Board and B. Carpenter, Ed., + "Charter of the Internet Architecture Board (IAB)", + BCP 39, RFC 2850, May 2000. + + + + [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, + . + + [IANADOCS] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, June 2017. + + + + [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, + . + + [IESG] Alvestrand, H., "An IESG charter", RFC 3710, + DOI 10.17487/RFC3710, February 2004, + . + + [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. + + + + [IPRRIGHTS1] + Bradner, S., Ed. and J. Contreras, Ed., "Rights + Contributors Provide to the IETF Trust", BCP 78, RFC 5378, + November 2008. + + + + [IPRRIGHTS2] + Bradner, S. and J. Contreras, "Intellectual Property + Rights in IETF Technology", BCP 79, RFC 8179, May 2017. + + + + [IRTF] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines + and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, + October 1996, . + + [IRTFCHAIR] + Eggert, L., "The Role of the IRTF Chair", RFC 7827, + DOI 10.17487/RFC7827, March 2016, + . + + [IRTFPRIMER] + Dawkins, S., Ed., "An IRTF Primer for IETF Participants", + RFC 7418, DOI 10.17487/RFC7418, December 2014, + . + + [ISOC] Internet Society, "Amended and restated By-Laws of the + Internet Society", May 2021, + . + + [ISOCIETF] Camarillo, G. and J. Livingood, "The IETF-ISOC + Relationship", RFC 8712, DOI 10.17487/RFC8712, February + 2020, . + + [MEETINGS] Krishnan, S., "High-Level Guidance for the Meeting Policy + of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719, + February 2020, . + + [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. + + + + [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in + the IETF Standards Process", BCP 11, RFC 2028, + DOI 10.17487/RFC2028, October 1996, + . + + [RFCEDMODEL] + Saint-Andre, P., Ed., "RFC Editor Model (Version 3)", + RFC 9280, DOI 10.17487/RFC9280, June 2022, + . + + [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, + . + + [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, . + + [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. + + + +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 -- cgit v1.2.3