]> Mozilla

Stenbergintie 12 B Kauniainen 02700 FI lars@eggert.org https://eggert.org/

Process Document Consolidation This document affirms that the IETF Chair may delegate some of their responsibilities to other Area Directors, and updates RFC 3710 and RFC 9281 to allow additional General Area Directors and to remove stale text. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the procon Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Throughout the history of the IETF, the role of the IETF Chair has always been filled by a single person. None of the foundational documents of the organization precisely define the role, but most are written with an understanding that the role is filled by a single person who is then tasked with numerous responsibilities. The expired Internet-Draft attempted to define the role of the IETF Chair more precisely but was not taken forward. Few documents explicitly say that the IETF Chair may delegate some of these responsibilities. Over time, this has created a situation where even a full-time commitment by a single person may no longer be sufficient to fulfill all of these roles and duties. There may also be periods of high activity where not all duties can be performed due to other, higher-priority tasks, or a seated IETF Chair may need to reduce their load for a while, for example for health or family reasons. A candidate for IETF Chair may also know in advance that they will not be able to perform all duties themselves. A delegation can therefore last from a short period up to the IETF Chair's entire term. An IETF Chair who is unable to serve at all is covered by . Single bottlenecks like this have obvious scaling and fault tolerance issues. This document hence explicitly allows the IETF Chair to delegate some of their responsibilities to one or more other Area Directors. It leaves it up to each IETF Chair to determine if they would like to delegate some of their responsibilities, and if so, which ones, to whom and when. This document does not require or even recommend that the IETF chair delegate any of their duties, it merely permits them to do so if they so choose. Specifically, with these changes, it should be possible for the IESG to request the selection of a General Area Director who is not at the same time also the IETF Chair, to whom the IETF Chair may then delegate some of their responsibilities. There must be community transparency about which tasks the IETF Chair has delegated to which other Area Director, and for which time. This transparency can be guaranteed in several ways, such as through the IESG website or public email. Such operational details are left to the discretion of the IESG.

Delegation The IETF Chair may delegate specific tasks or functions of their roles to one or more other Area Directors who agree to take them on, unless a BCP specifically disallows this. Each delegation is for a specific period of time and is announced. The IETF Chair continues to hold their roles and retains ultimate responsibility for any delegated tasks or functions. This includes the IESG Chair's part in the appeals process (): the IETF Chair may ask another Area Director to help resolve a complaint but remains responsible for the outcome. Delegation is limited to Area Directors, because the NomCom selected them for the IESG and they are accountable through the NomCom and recall processes. This also preserves the separation between the IAB and the standards process, and prevents candidates for IETF Chair from campaigning as teams. The NomCom may ask candidates for IETF Chair which tasks they intend to delegate. If the IETF Chair is absent from an IESG meeting and has not delegated chairing it, the IESG may choose who chairs that meeting.

Additional General Area Directors The IESG may ask the NomCom to fill one or more additional General Area Director positions, just as it has added Area Directors to other areas and created new areas. The IETF Chair remains a General Area Director. To allow this, this document makes the following updates:

1. In , replace "who also functions as the General Area Director" with "who also functions as a General Area Director".
2. In , replace "is the AD for the General Area" with "is an AD for the General Area".

Other Updates This section collects updates to some text in existing RFCs that has become stale.

Staff Supervision says

• The IETF Chair has primary responsibility for supervising the work of the IETF Secretariat, with the advice and consent of the IESG, the IAB Chair and the ISOC president.

With the publication of , this responsibility has moved to the IETF Executive Director (). The document updates to remove the sentence above.

Security Considerations The usual security considerations do not apply to this document.

IANA Considerations This document has no IANA actions.

Acknowledgments These individuals suggested improvements to this document:

• Alvaro Retana
• Brian Carpenter
• Colin Perkins
• Eliot Lear
• Eric Rescorla
• Jari Arkko
• Joel Halpern
• John Klensin
• Leslie Daigle
• Michael Richardson
• Mirja Kühlewind
• Russ Housley
• Suresh Krishnan

References Normative References This memo documents the process used by the Internet community for the standardization of protocols and procedures. It 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 specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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. Internet Architecture Board This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents. This document obsoletes RFC 7437 and RFC 8318. Informative References IBM This document describes tasks performed by the IETF Chair, the IESG Chair, and the Area Director of the General Area of the IETF. Its purpose is to inform the community of what these tasks are, and to allow the community to consider whether combining all these roles in one person is optimal. Mozilla This document defines a succession of emergency stand-ins in case the IETF Chair becomes incapacitated. This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community. The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board. This document obsoletes RFC 4071, RFC 4333, and RFC 7691. All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Akamai Technologies Harvard University (retired) This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages, and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. Internet Architecture Board Internet Engineering Steering Group This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them. This memo provides information for the Internet community. Internet Architecture Board This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work. This document is an updated version of the guidelines for conduct originally published in RFC 3184. IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy. This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories. The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope. This document obsoletes RFC 3005 and updates RFC 3683. This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein. This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730.

The IETF Chair and IESG Chair Roles This section analyzes which RFCs imply that the IETF Chair and IESG Chair roles need to be filled by the same person.

Background is surprisingly silent on the role of the IETF Chair, only mentioning it in as part of the terminology:

• Area Director - The manager of an IETF Area. The Area Directors along with the IETF Chair comprise the Internet Engineering Steering Group (IESG). Internet Engineering Steering Group (IESG) - A group comprised of the IETF Area Directors and the IETF Chair. (...)

Similarly, the role of the IESG Chair is only briefly mentioned in as part of how process failures are handled:

• If an individual should disagree with an action taken by the IESG in this process, that person should first discuss the issue with the IESG Chair. If the IESG Chair is unable to satisfy the complainant then (...)

does not require the IETF Chair to also fulfill the role of IESG Chair. , the earlier revision of the standards process that obsoletes, is an Informational RFC and does include text to that effect, however:

• The IESG is composed of the IETF Area Directors and the chairperson of the IETF, who also serves as the chairperson of the IESG.

is likely the basis for , a BCP that includes similar text:

• The IESG is composed of the IETF Area Directors and the chair of the IETF, who also serves as the chair of the IESG.

, a BCP that obsoletes , retains that text and also states that the IETF Chair is the Area Director for the General Area:

• 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.

, an Informational RFC containing an Internet Security Glossary, contains this text under the "Internet Engineering Steering Group (IESG)" glossary item:

• The part of the ISOC responsible for technical management of IETF activities and administration of the Internet Standards Process according to procedures approved by the ISOC Trustees. Directly responsible for actions along the "standards track", including final approval of specifications as Internet Standards. Composed of IETF Area Directors and the IETF chairperson, who also chairs the IESG. (RFC 2026)

Delegation of IESG Chair Tasks These texts are consistent with : the IETF Chair chairs the IESG and only delegates specific tasks.

IAB Membership This section analyzes which RFCs contain text about the full IAB membership of the IETF Chair.

Background requires the IETF Chair to be a full member of the IAB:

• The Internet Architecture Board (IAB) shall consist of thirteen full members, composed of the chair of the Internet Engineering Task Force (IETF), and of twelve sitting members.

contains a similar statement as part of the second item in a list of "oral traditions" recorded for "consideration by future NomComs":

• No person should serve both on the IAB and as an Area Director, except the IETF Chair whose roles as an IAB member and Area Director of the General Area are set out elsewhere.

says:

• 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.

IAB Member Role The IETF Chair remains a full voting member of the IAB and may choose to participate less in IAB activities when needed. is an IAB-stream BCP, so any change to the IETF Chair's IAB membership is for the IAB to make.

General Area Director Role This section analyzes which RFCs contain text about the responsibility of the IETF Chair to also serve as Area Director of the General Area.

Background states that the IETF Chair is the General Area Director:

• The IETF Chair, who also functions as the General Area Director when this area is active

also makes a similar statement:

• The IETF Chair also chairs the IESG and is the AD for the General Area.

Additional General Area Directors Both texts imply a single General Area Director. updates them so that the IESG may ask the NomCom to fill additional General Area Director positions.

Other Roles This section briefly summarizes other roles the IETF Chair has, but which require no updates, usually because delegation is already permitted.

Liaison Statements says

• Liaison statements are only sent on the initiative of the IETF chair, the IAB chair, IETF Area Directors, or IETF working group chairs.

says

• For a liaison statement generated on behalf of the IETF as a whole, the IETF Chair must have generated or must agree with the sending of the liaison statement. If the liaison statement is not sent by the IETF Chair, then his or her agreement must be obtained in advance and confirmed by copying the IETF Chair on the message.

The combination of these two statements already allows another Area Director to send a liaison statement on behalf of the IETF with IETF Chair approval.

Transgressions of the IETF Guidelines for Conduct says "An individual can report transgressions of the guidelines for conduct to the IETF Chair or the IESG." does not define any actions specific to the IETF Chair for such reports, so receiving them can be delegated like other tasks ().

Appointments to the Ombuds-, Moderator and Last-Call List Moderation Teams The IETF Chair is tasked with managing the constituency of the ombudsteam and the moderator team of the IETF discussion list . They also select moderators for the Last-Call mailing list, and other lists with an organizational scope encompassing the entire IETF. The IETF Chair may delegate the work of soliciting and vetting candidates (), but makes these appointments themselves, as makes the ombudsteam appointment "solely the responsibility of the IETF Chair". No changes are made here.

Serving on the IETF LLC Board suggests that the IETF Chair, or a delegate selected by the IESG, will serve on the Board of Directors of the IETF Administration LLC. Because delegation of that role is already explicitly allowed, no changes are made here.

Serving on the RFC Series Approval Board makes the IETF stream representative on the RFC Series Approval Board "either an IESG member or someone appointed by the IESG". Because this already allows someone other than the IETF Chair to serve, no changes are made here.

Changes since draft-eggert-procon-chair-delegate-02

• Allow delegating specific tasks instead of whole roles, with the IETF Chair retaining ultimate responsibility.
• Keep the IESG Chair role and the IAB membership with the IETF Chair, and drop the corresponding updates to RFC 2850, RFC 4949 and RFC 8713.
• Address the IESG Chair's part in the appeals process.
• Let the IESG choose who chairs a meeting when the IETF Chair is absent.
• Allow additional General Area Directors, updating RFC 3710 and RFC 9281.
• Describe the situations in which delegation may be needed.
• Let the NomCom ask IETF Chair candidates about their delegation plans.
• Explain why delegation is limited to Area Directors.
• Cover the RSAB seat, conduct reports and team appointments.
• Move the analysis of existing RFCs into appendices.
• Editorial fixes.