Movatterモバイル変換


[0]ホーム

URL:


RFC 9281Entities in IETF Standards ProcessJune 2022
SalzBest Current Practice[Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
9281
BCP:
11
Obsoletes:
2028
Category:
Best Current Practice
Published:
ISSN:
2070-1721
Author:
R. Salz
Akamai Technologies

RFC 9281

Entities Involved in the IETF Standards Process

Abstract

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

The IETF and its structure have undergone many changes since RFC2028 was published in 1996. This document reflects the changed organizationalstructure 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 athttps://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

The process used by the IETF community for the standardization ofprotocols and procedures is described in BCP 9[IETFPROCS].BCP 9 definesthe stages in the standardization process, the requirements formoving a document between stages, and the types of documents usedduring this process.This document identifies some of the key individual roles and organizationsin 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 sametime.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) andreorderedSection 2 to follow the typical workflow.
  • Added the IETF Administration LLC and the IETF Trust toSection 3.
  • Changed "RFC Editor" to "RFC Production Center" to reflect the changesmade by[RFCEDMODEL].
  • Added theTerminology andAcknowledgements sections.
  • Cleaned up some wordingthroughout 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 involvedin the process, without otherwise expressing significance.

2.1.Document Editor or Author

Most working groups (WGs) focus their efforts on one or more documentsthat capture their work results. The WG chair designates one or more peopleto serve as the editor(s)for a particular document. The editor is responsible forensuring that the contents of the document accurately reflect thedecisions 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 isnot significant for the standards process.This document uses the term "document editor".

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

2.2.Working Group Chair

Each WG is headed by a chair who hasthe responsibility for facilitating the group's activities, presidingover the group's meetings, and ensuring that the commitments of thegroup with respect to its role in the Internet standards process aremet. In particular, the WG chair is the formal point of contactbetween the WG and the Internet Engineering Steering Group (IESG), via the AD of the area towhich the WG belongs.

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

2.3.Area Director

Each WG is assigned a single responsible area director (AD).The AD canassist the WG chair in assessing consensus and executing process.The AD also reviews documents after the WG has approved them, andwhen satisfied, the ADcoordinates the IESG review and IETF Last Call ofthe 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 inthe Internet standards process.

3.1.Internet Engineering Task Force (IETF)

The IETF is an open internationalcommunity of network designers, operators, implementors, researchers,and other interested parties who areconcerned with the evolution of the Internet architecture and thesmooth operation of the Internet. It is the principal body engagedin 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, whichare organized by topics into severalareas,each under the coordination of an AD.WGs typically have a narrow focus and a lifetime boundedby completion of specific tasks as defined in their charterand milestones. Some WGs are long-lived and intended to conductongoing maintenance on IETF protocol(s). There are also "dispatch" WGsthat assess where new work in the IETF should be done but donot directly produce standards.

For all purposes relevant to the Internet Standards developmentprocess, membership in the IETF and its WGs is defined tobe established solely and entirely by individuals whoparticipate inIETF 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 toparticipate actively in one or more WGs and to attendIETF meetings, which are usually heldthree 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 attendingany in-person meetings.

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

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

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

WGs ideally display a spirit of cooperation as well as a highdegree of technical maturity; IETF participants recognize that thegreatest benefit for all members of the Internet community resultsfrom cooperative development of technically excellent protocols andservices.

3.3.Internet Engineering Steering Group (IESG)

The IESG isresponsible for the management of the IETF technicalactivities. It administers the Internet Standards process accordingto the rules and procedures defined in[IETFPROCS]. The IESG is responsiblefor the actions associated with the progression of documentsalong the IETF Stream, including the initialapproval of new WGs, any subsequentrechartering, and the final approval ofdocuments. The IESG is composed of theADs and the IETF Chair. The IETF Chair also chairs the IESG andis 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 detaileddescription of the NomCom procedures. Other matters concerning theorganization 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 itsprotocols. The IAB approves IESG candidates put forward by theNomCom. It also reviews all proposed IETF WG charters.

The IAB provides oversight of the standards processand serves as an appeal board for related complaints about improperexecution[IETFPROCS]. In general, it acts as a sourceof advice abouttechnical, architectural, procedural, and policy matterspertaining to the Internet and its enabling technologies.

The members of the IAB are nominated by the NomComand are confirmed by the Board of the Internet Society (ISOC).The IETF Chair is also a member of the IAB, and theChair of the Internet Research Task Force (IRTF) is an ex officio member.Othermatters concerning the IAB's organization and operation are described in the IABCharter[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 RFCSeries Working Group (RSWG), an open group (similar to IETF WGs),and approved by the RFC Series AdvisoryBoard (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 Section4.

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 maintainingseveral aspects of the DNS andcoordinating of IP address assignments.

3.7.Internet Research Task Force (IRTF)

The IRTF focuses on longer-term research issues related to the Internet as aparallel organization to the IETF, whichfocuses on the shorter-term issues of engineering, operations, andspecification of standards.

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

The IRTF is managed by the IRTF Chair in consultation with the InternetResearch 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 organizationand 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 intellectualproperty for the IETF, IRTF, and IAB.This includes their trademarks, the copyrights to RFCs and to worksof the IETF such as the IETF website, andcopyright licenses for IETF contributions including Internet-Drafts.The principles for the copyright licenses granted to and from theTrust are described in[IPRRIGHTS1]and[COPYRIGHT], and the licenses themselves are in theTrust Legal Provisions.

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

The Trustees that govern the Trust are selected from the IETF community, asdescribed 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") providesthe corporate legal home for the IETF, the IAB, and the IRTF.

The IETF LLC is responsible for supporting the ongoing operationsof 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 IETFSecretariat, meeting hotels, tools development contractors, among many others.The IETF LLC also responds to legal requests; these are often subpoenasin 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 managementand is overseen by the IETF LLC Board of Directors.

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

3.10.IETF Secretariat

The administrative functions necessary to support the activities ofthe IETF and its various related boards and organizationsare performed by a Secretariat contracted by the IETF LLC.The IETF Secretariat handles much of the logistics of running the in-personmeetings and is responsible formaintaining the formal public record of the Internet standardsprocess[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 isselected and other matters concerning the operation of the InternetSociety 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,,<https://www.rfc-editor.org/info/rfc8721>.
[IAB]
Internet Architecture Board andB. Carpenter, Ed.,"Charter of the Internet Architecture Board (IAB)",BCP 39,RFC 2850,.
<https://www.rfc-editor.org/info/bcp39>
[IABIRTF]
Floyd, S., Ed.,Paxson, V., Ed.,Falk, A., Ed., andIAB,"IAB Thoughts on the Role of the Internet Research Task Force (IRTF)",RFC 4440,DOI 10.17487/RFC4440,,<https://www.rfc-editor.org/info/rfc4440>.
[IANADOCS]
Cotton, M.,Leiba, B., andT. Narten,"Guidelines for Writing an IANA Considerations Section in RFCs",BCP 26,RFC 8126,.
<https://www.rfc-editor.org/info/bcp26>
[IANAMOU]
Carpenter, B.,Baker, F., andM. Roberts,"Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority",RFC 2860,DOI 10.17487/RFC2860,,<https://www.rfc-editor.org/info/rfc2860>.
[IESG]
Alvestrand, H.,"An IESG charter",RFC 3710,DOI 10.17487/RFC3710,,<https://www.rfc-editor.org/info/rfc3710>.
[IETFPROCS]
Bradner, S.,"The Internet Standards Process -- Revision 3",BCP 9,RFC 2026,.
Dusseault, L. andR. Sparks,"Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard",BCP 9,RFC 5657,.
Housley, R.,Crocker, D., andE. Burger,"Reducing the Standards Track to Two Maturity Levels",BCP 9,RFC 6410,.
Resnick, P.,"Retirement of the "Internet Official Protocol Standards" Summary Document",BCP 9,RFC 7100,.
Kolkman, O.,Bradner, S., andS. Turner,"Characterization of Proposed Standards",BCP 9,RFC 7127,.
Dawkins, S.,"Increasing the Number of Area Directors in an IETF Area",BCP 9,RFC 7475,.
Halpern, J., Ed. andE. Rescorla, Ed.,"IETF Stream Documents Require IETF Rough Consensus",BCP 9,RFC 8789,.
<https://www.rfc-editor.org/info/bcp9>
[IPRRIGHTS1]
Bradner, S., Ed. andJ. Contreras, Ed.,"Rights Contributors Provide to the IETF Trust",BCP 78,RFC 5378,.
<https://www.rfc-editor.org/info/bcp78>
[IPRRIGHTS2]
Bradner, S. andJ. Contreras,"Intellectual Property Rights in IETF Technology",BCP 79,RFC 8179,.
<https://www.rfc-editor.org/info/bcp79>
[IRTF]
Weinrib, A. andJ. Postel,"IRTF Research Group Guidelines and Procedures",BCP 8,RFC 2014,DOI 10.17487/RFC2014,,<https://www.rfc-editor.org/info/rfc2014>.
[IRTFCHAIR]
Eggert, L.,"The Role of the IRTF Chair",RFC 7827,DOI 10.17487/RFC7827,,<https://www.rfc-editor.org/info/rfc7827>.
[IRTFPRIMER]
Dawkins, S., Ed.,"An IRTF Primer for IETF Participants",RFC 7418,DOI 10.17487/RFC7418,,<https://www.rfc-editor.org/info/rfc7418>.
[ISOC]
Internet Society,"Amended and restated By-Laws of the Internet Society",,<https://www.internetsociety.org/about-internet-society/governance-policies/by-laws/>.
[ISOCIETF]
Camarillo, G. andJ. Livingood,"The IETF-ISOC Relationship",RFC 8712,DOI 10.17487/RFC8712,,<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,,<https://www.rfc-editor.org/info/rfc8719>.
[NOMCOM]
Kucherawy, M., Ed.,Hinden, R., Ed., andJ. 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,.
Leiba, B.,"Eligibility for the 2020-2021 Nominating Committee",BCP 10,RFC 8788,.
<https://www.rfc-editor.org/info/bcp10>
[RFC2028]
Hovey, R. andS. Bradner,"The Organizations Involved in the IETF Standards Process",BCP 11,RFC 2028,DOI 10.17487/RFC2028,,<https://www.rfc-editor.org/info/rfc2028>.
[RFCEDMODEL]
Saint-Andre, P., Ed.,"RFC Editor Model (Version 3)",RFC 9280,DOI 10.17487/RFC9280,,<https://www.rfc-editor.org/info/rfc9280>.
[TRUSTEES]
Arkko, J. andT. Hardie,"Update to the Process for Selection of Trustees for the IETF Trust",BCP 101,RFC 8714,DOI 10.17487/RFC8714,,<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,,<https://www.rfc-editor.org/info/rfc8715>.
[WGPROCS]
Bradner, S.,"IETF Working Group Guidelines and Procedures",BCP 25,RFC 2418,.
Wasserman, M.,"Updates to RFC 2418 Regarding the Management of IETF Mailing Lists",BCP 25,RFC 3934,.
Resnick, P. andA. Farrel,"IETF Anti-Harassment Procedures",BCP 25,RFC 7776,.
Resnick, P. andA. 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,.
<https://www.rfc-editor.org/info/bcp25>

Acknowledgements

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

Barry Leiba,Colin Perkins,Eric Auerswald,John Levine, andLars Eggertprovided useful feedback and corrections to this document.

Author's Address

Rich Salz
Akamai Technologies
Email:rsalz@akamai.com

[8]ページ先頭

©2009-2026 Movatter.jp