rfc2418.txt   draft-ietf-procon-2418bis-01.txt 
Network Working Group S. Bradner procon R. Salz
Request for Comments: 2418 Editor Internet-Draft Akamai Technologies
Obsoletes: 1603 Harvard University Obsoletes: 2418, 3934 (if approved) D. Schinazi
BCP: 25 September 1998 Updates: 7475, 7776, 8717, 9141 (if approved) Google LLC
Category: Best Current Practice Intended status: Best Current Practice S. Bradner
Expires: 19 April 2026 SOBCO
IETF Working Group 16 October 2025
Guidelines and Procedures
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. IETF Working Group Guidelines and Procedures
draft-ietf-procon-2418bis-01
Abstract Abstract
The Internet Engineering Task Force (IETF) has responsibility for The Internet Engineering Task Force (IETF) has responsibility for
developing and reviewing specifications intended as Internet developing and reviewing specifications intended as Internet
Standards. IETF activities are organized into working groups (WGs). Standards. IETF activities are organized into working groups (WGs).
This document describes the guidelines and procedures for formation This document describes the guidelines and procedures for formation
and operation of IETF working groups. It also describes the formal and operation of IETF working groups. It also describes the formal
relationship between IETF participants WG and the Internet relationship between IETF participants WG and the Internet
Engineering Steering Group (IESG) and the basic duties of IETF Engineering Steering Group (IESG) and the basic duties of IETF
participants, including WG Chairs, WG participants, and IETF Area participants, including WG Chairs, WG participants, and IETF Area
Directors. Directors.
Table of Contents This document obsoletes RFC2418, and RFC3934. It also includes the
changes from RFC7475, and with [_2026bis], obsoletes it. It also
includes a summary of the changes implied in RFC7776 and incorporates
the changes from RFC8717 and RFC9141.
Abstract ......................................................... 1 About This Document
1. Introduction .................................................. 2
1.1. IETF approach to standardization .......................... 4
1.2. Roles within a Working Group .............................. 4
2. Working group formation ....................................... 4
2.1. Criteria for formation .................................... 4
2.2. Charter ................................................... 6
2.3. Charter review & approval ................................. 8
2.4. Birds of a feather (BOF) .................................. 9
3. Working Group Operation ....................................... 10
3.1. Session planning .......................................... 11
3.2. Session venue ............................................. 11
3.3. Session management ........................................ 13
3.4. Contention and appeals .................................... 15
4. Working Group Termination ..................................... 15 This note is to be removed before publishing as an RFC.
5. Rechartering a Working Group .................................. 15
6. Staff Roles ................................................... 16
6.1. WG Chair .................................................. 16
6.2. WG Secretary .............................................. 18
6.3. Document Editor ........................................... 18
6.4. WG Facilitator ............................................ 18
6.5. Design teams .............................................. 19
6.6. Working Group Consultant .................................. 19
6.7. Area Director ............................................. 19
7. Working Group Documents ....................................... 19
7.1. Session documents ......................................... 19
7.2. Internet-Drafts (I-D) ..................................... 19
7.3. Request For Comments (RFC) ................................ 20
7.4. Working Group Last-Call ................................... 20
7.5. Submission of documents ................................... 21
8. Review of documents ........................................... 21
9. Security Considerations ....................................... 22
10. Acknowledgments .............................................. 23
11. References ................................................... 23
12. Editor's Address ............................................. 23
Appendix: Sample Working Group Charter .......................... 24
Full Copyright Statement ......................................... 26
1. Introduction Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-procon-2418bis/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-procon/2418bis.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 April 2026.
Copyright Notice
Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IETF approach to standardization . . . . . . . . . . . . 4
1.2. Roles within a Working Group . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Working group formation . . . . . . . . . . . . . . . . . . . 5
3.1. Criteria for formation . . . . . . . . . . . . . . . . . 5
3.2. Charter . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Charter review & approval . . . . . . . . . . . . . . . . 9
3.4. Birds of a Feather (BOF) . . . . . . . . . . . . . . . . 10
4. Working Group Operation . . . . . . . . . . . . . . . . . . . 11
4.1. Session planning . . . . . . . . . . . . . . . . . . . . 12
4.2. Session venue . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. IETF Meetings . . . . . . . . . . . . . . . . . . . . 13
4.2.2. On-line . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Session management . . . . . . . . . . . . . . . . . . . 15
4.4. Contention and appeals . . . . . . . . . . . . . . . . . 16
5. Working Group Termination . . . . . . . . . . . . . . . . . . 17
6. Rechartering a Working Group . . . . . . . . . . . . . . . . 17
7. Staff Roles . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. WG Chair . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. WG Secretary . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Document Editor . . . . . . . . . . . . . . . . . . . . . 20
7.4. WG Facilitator . . . . . . . . . . . . . . . . . . . . . 20
7.5. Design teams . . . . . . . . . . . . . . . . . . . . . . 20
7.6. Working Group Consultant . . . . . . . . . . . . . . . . 21
7.7. Area Director . . . . . . . . . . . . . . . . . . . . . . 21
7.8. Ombudsteam . . . . . . . . . . . . . . . . . . . . . . . 21
8. Working Group Documents . . . . . . . . . . . . . . . . . . . 21
8.1. Session documents . . . . . . . . . . . . . . . . . . . . 21
8.2. Internet-Drafts (I-D) . . . . . . . . . . . . . . . . . . 22
8.3. Request For Comments (RFC) . . . . . . . . . . . . . . . 22
8.4. Working Group Last-Call . . . . . . . . . . . . . . . . . 23
8.5. Submission of documents . . . . . . . . . . . . . . . . . 23
9. Review of documents . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Working group draft . . . . . . . . . . . . . . . . . . 25
12.2. Individual draft . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
The Internet, a loosely-organized international collaboration of The Internet, a loosely-organized international collaboration of
autonomous, interconnected networks, supports host-to-host autonomous, interconnected networks, supports host-to-host
communication through voluntary adherence to open protocols and communication through voluntary adherence to open protocols and
procedures defined by Internet Standards. There are also many procedures defined by Internet Standards. There are also many
isolated interconnected networks, which are not connected to the isolated interconnected networks, which are not connected to the
global Internet but use the Internet Standards. Internet Standards global Internet but use the Internet Standards. Internet Standards
are developed in the Internet Engineering Task Force (IETF). This are developed in the Internet Engineering Task Force (IETF). This
document defines guidelines and procedures for IETF working groups. document defines guidelines and procedures for IETF working groups.
The Internet Standards Process of the IETF is defined in [1]. The The Internet Standards Process of the IETF is defined in [_2026bis].
organizations involved in the IETF Standards Process are described in The organizations involved in the IETF Standards Process are
[2] as are the roles of specific individuals. described in [RFC9281] as are the roles of specific individuals.
The IETF is a large, open community of network designers, operators, The IETF is a large, open community of network designers, operators,
vendors, users, and researchers concerned with the Internet and the vendors, users, and researchers concerned with the Internet and the
technology used on it. The primary activities of the IETF are technology used on it. The primary activities of the IETF are
performed by committees known as working groups. There are currently performed by committees known as working groups. There are currently
more than 100 working groups. (See the IETF web page for an up-to- more than 100 working groups. (See the Datatracker web page
date list of IETF Working Groups - http://www.ietf.org.) Working (https://datatracker.ietf.org/wg/) for an up-to-date list of IETF
groups tend to have a narrow focus and a lifetime bounded by the Working Groups.) Working groups tend to have a narrow focus and a
completion of a specific set of tasks, although there are exceptions. lifetime bounded by the completion of a specific set of tasks,
although there are exceptions.
For management purposes, the IETF working groups are collected For management purposes, the IETF working groups are collected
together into areas, with each area having a separate focus. For together into areas, with each area having a separate focus. For
example, the security area deals with the development of security- example, the security area deals with the development of security-
related technology. Each IETF area is managed by one or two Area related technology. Each IETF area is managed by one or more Area
Directors (ADs). There are currently 8 areas in the IETF but the Directors (ADs). There are currently seven areas in the IETF but the
number changes from time to time. (See the IETF web page for a list number changes from time to time. (See the IETF web page
of the current areas, the Area Directors for each area, and a list of (https://www.ietf.org/technologies/areas/) for a list of the current
which working groups are assigned to each area.) areas, the Area Directors for each area, and a list of which working
groups are assigned to each area.)
In many areas, the Area Directors have formed an advisory group or In many areas, the Area Directors have formed an advisory group or
directorate. These comprise experienced members of the IETF and the directorate. These comprise experienced members of the IETF and the
technical community represented by the area. The specific name and technical community represented by the area. The specific name and
the details of the role for each group differ from area to area, but the details of the role for each group differ from area to area, but
the primary intent is that these groups assist the Area Director(s), the primary intent is that these groups assist the Area Director(s),
e.g., with the review of specifications produced in the area. e.g., with the review of specifications produced in the area.
The IETF area directors are selected by a nominating committee, which The IETF area directors are selected by a nominating committee, which
also selects an overall chair for the IETF. The nominations process also selects an overall chair for the IETF. The nominations process
is described in [3]. is described in [RFC8713].
The area directors sitting as a body, along with the IETF Chair, The area directors sitting as a body, along with the IETF Chair,
comprise the Internet Engineering Steering Group (IESG). The IETF comprise the Internet Engineering Steering Group (IESG). The
Executive Director is an ex-officio participant of the IESG, as are Internet Architecture Board (IAB) Chair and the IETF Executive
the IAB Chair and a designated Internet Architecture Board (IAB) Director are ex-officio members of the IESG. There are also liaisons
liaison. The IESG approves IETF Standards and approves the from IANA, the RFC Production Center, the Secretariat, and the IAB.
publication of other IETF documents. (See [1].) The IESG approves IETF Standards and approves the publication of
other IETF documents. (See [_2026bis].)
A small IETF Secretariat provides staff and administrative support The IETF Secretariat provides staff and administrative support for
for the operation of the IETF. the operation of the IETF.
There is no formal membership in the IETF. Participation is open to There is no formal membership in the IETF. Participation is open to
all. This participation may be by on-line contribution, attendance all. This participation may be by on-line contribution, attendance
at face-to-face sessions, or both. Anyone from the Internet at face-to-face sessions, or both. Anyone from the Internet
community who has the time and interest is urged to participate in community who has the time and interest is urged to participate in
IETF meetings and any of its on-line working group discussions. IETF meetings and any of its on-line working group discussions.
Participation is by individual technical contributors, rather than by Participation is by individual technical contributors, rather than by
formal representatives of organizations. formal representatives of organizations.
This document defines procedures and guidelines for the formation and This document defines procedures and guidelines for the formation and
operation of working groups in the IETF. It defines the relations of operation of working groups in the IETF. It defines the relations of
working groups to other bodies within the IETF. The duties of working working groups to other bodies within the IETF. The duties of
group Chairs and Area Directors with respect to the operation of the working group Chairs and Area Directors with respect to the operation
working group are also defined. When used in this document the key of the working group are also defined.
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
interpreted as described in RFC 2119 [6]. RFC 2119 defines the use
of these key words to help make the intent of standards track
documents as clear as possible. The same key words are used in this
document to help smooth WG operation and reduce the chance for
confusion about the processes.
1.1. IETF approach to standardization 1.1. IETF approach to standardization
Familiarity with The Internet Standards Process [1] is essential for Familiarity with The Internet Standards Process [_2026bis] is
a complete understanding of the philosophy, procedures and guidelines essential for a complete understanding of the philosophy, procedures
described in this document. and guidelines described in this document.
1.2. Roles within a Working Group 1.2. Roles within a Working Group
The document, "Organizations Involved in the IETF Standards Process" The document, "Organizations Involved in the IETF Standards Process"
[2] describes the roles of a number of individuals within a working [RFC9281] describes the roles of a number of individuals within a
group, including the working group chair and the document editor. working group, including the working group chair and the document
These descriptions are expanded later in this document. editor. These descriptions are expanded later in this document.
2. Working group formation 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Working group formation
IETF working groups (WGs) are the primary mechanism for development IETF working groups (WGs) are the primary mechanism for development
of IETF specifications and guidelines, many of which are intended to of IETF specifications and guidelines, many of which are intended to
be standards or recommendations. A working group may be established be standards or recommendations. A working group may be established
at the initiative of an Area Director or it may be initiated by an at the initiative of an Area Director or it may be initiated by an
individual or group of individuals. Anyone interested in creating an individual or group of individuals. Anyone interested in creating an
IETF working group MUST obtain the advice and consent of the IETF IETF working group MUST obtain the advice and consent of the IETF
Area Director(s) in whose area the working group would fall and MUST Area Director(s) in whose area the working group would fall and MUST
proceed through the formal steps detailed in this section. proceed through the formal steps detailed in this section.
Working groups are typically created to address a specific problem or Working groups are typically created to address a specific problem or
to produce one or more specific deliverables (a guideline, standards to produce one or more specific deliverables (a guideline, standards
specification, etc.). Working groups are generally expected to be specification, etc.). Working groups are generally expected to be
short-lived in nature. Upon completion of its goals and achievement short-lived in nature. Upon completion of its goals and achievement
of its objectives, the working group is terminated. A working group of its objectives, the working group is terminated. A working group
may also be terminated for other reasons (see section 4). may also be terminated for other reasons (see Section 5).
Alternatively, with the concurrence of the IESG, Area Director, the Alternatively, with the concurrence of the IESG, Area Director, the
WG Chair, and the WG participants, the objectives or assignment of WG Chair, and the WG participants, the objectives or assignment of
the working group may be extended by modifying the working group's the working group may be extended by modifying the working group's
charter through a rechartering process (see section 5). charter through a rechartering process (see Section 6).
2.1. Criteria for formation 3.1. Criteria for formation
When determining whether it is appropriate to create a working group, When determining whether it is appropriate to create a working group,
the Area Director(s) and the IESG will consider several issues: the Area Director(s) and the IESG will consider several issues:
- Are the issues that the working group plans to address clear and * Are the issues that the working group plans to address clear and
relevant to the Internet community? relevant to the Internet community?
- Are the goals specific and reasonably achievable, and achievable * Are the goals specific and reasonably achievable, and achievable
within a reasonable time frame? within a reasonable time frame?
- What are the risks and urgency of the work, to determine the level * What are the risks and urgency of the work, to determine the level
of effort required? of effort required?
- Do the working group's activities overlap with those of another * Do the working group's activities overlap with those of another
working group? If so, it may still be appropriate to create the working group? If so, it may still be appropriate to create the
working group, but this question must be considered carefully by working group, but this question must be considered carefully by
the Area Directors as subdividing efforts often dilutes the the Area Directors as subdividing efforts often dilutes the
available technical expertise. available technical expertise.
- Is there sufficient interest within the IETF in the working * Is there sufficient interest within the IETF in the working
group's topic with enough people willing to expend the effort to group's topic with enough people willing to expend the effort to
produce the desired result (e.g., a protocol specification)? produce the desired result (e.g., a protocol specification)?
Working groups require considerable effort, including management Working groups require considerable effort, including management
of the working group process, editing of working group documents, of the working group process, editing of working group documents,
and contributing to the document text. IETF experience suggests and contributing to the document text. IETF experience suggests
that these roles typically cannot all be handled by one person; a that these roles typically cannot all be handled by one person; a
minimum of four or five active participants in the management minimum of four or five active participants in the management
positions are typically required in addition to a minimum of one positions are typically required in addition to a minimum of one
or two dozen people that will attend the working group meetings or two dozen people that will attend the working group meetings
and contribute on the mailing list. NOTE: The interest must be and contribute on the mailing list. NOTE: The interest must be
broad enough that a working group would not be seen as merely the broad enough that a working group would not be seen as merely the
activity of a single vendor. activity of a single vendor.
- Is there enough expertise within the IETF in the working group's * Is there enough expertise within the IETF in the working group's
topic, and are those people interested in contributing in the topic, and are those people interested in contributing in the
working group? working group?
- Does a base of interested consumers (end-users) appear to exist * Does a base of interested consumers (end-users) appear to exist
for the planned work? Consumer interest can be measured by for the planned work? Consumer interest can be measured by
participation of end-users within the IETF process, as well as by participation of end-users within the IETF process, as well as by
less direct means. less direct means.
- Does the IETF have a reasonable role to play in the determination * Does the IETF have a reasonable role to play in the determination
of the technology? There are many Internet-related technologies of the technology? There are many Internet-related technologies
that may be interesting to IETF members but in some cases the IETF that may be interesting to IETF members but in some cases the IETF
may not be in a position to effect the course of the technology in may not be in a position to effect the course of the technology in
the "real world". This can happen, for example, if the technology the "real world". This can happen, for example, if the technology
is being developed by another standards body or an industry is being developed by another standards body or an industry
consortium. consortium.
- Are all known intellectual property rights relevant to the * Are all known intellectual property rights relevant to the
proposed working group's efforts issues understood? proposed working group's efforts issues understood?
- Is the proposed work plan an open IETF effort or is it an attempt * Is the proposed work plan an open IETF effort or is it an attempt
to "bless" non-IETF technology where the effect of input from IETF to "bless" non-IETF technology where the effect of input from IETF
participants may be limited? participants may be limited?
- Is there a good understanding of any existing work that is * Is there a good understanding of any existing work that is
relevant to the topics that the proposed working group is to relevant to the topics that the proposed working group is to
pursue? This includes work within the IETF and elsewhere. pursue? This includes work within the IETF and elsewhere.
- Do the working group's goals overlap with known work in another * Do the working group's goals overlap with known work in another
standards body, and if so is adequate liaison in place? standards body, and if so is adequate liaison in place?
Considering the above criteria, the Area Director(s), using his or Considering the above criteria, the Area Director(s), using his or
her best judgement, will decide whether to pursue the formation of her best judgement, will decide whether to pursue the formation of
the group through the chartering process. the group through the chartering process.
2.2. Charter 3.2. Charter
The formation of a working group requires a charter which is The formation of a working group requires a charter which is
primarily negotiated between a prospective working group Chair and primarily negotiated between a prospective working group Chair and
the relevant Area Director(s), although final approval is made by the the relevant Area Director(s), although final approval is made by the
IESG with advice from the Internet Architecture Board (IAB). A IESG with advice from the IAB. A charter is a contract between a
charter is a contract between a working group and the IETF to perform working group and the IETF to perform a set of tasks. A charter:
a set of tasks. A charter:
1. Lists relevant administrative information for the working group; 1. Lists relevant administrative information for the working group;
2. Specifies the direction or objectives of the working group and
describes the approach that will be taken to achieve the goals; 2. Specifies the direction or objectives of the working group and
and describes the approach that will be taken to achieve the goals;
3. Enumerates a set of milestones together with time frames for their and
completion.
3. Optionally enumerates a set of milestones together with time
frames for their completion.
When the prospective Chair(s), the Area Director and the IETF When the prospective Chair(s), the Area Director and the IETF
Secretariat are satisfied with the charter form and content, it Secretariat are satisfied with the charter form and content, it
becomes the basis for forming a working group. Note that an Area becomes the basis for forming a working group. Note that an Area
Director MAY require holding an exploratory Birds of a Feather (BOF) Director MAY require holding an exploratory Birds of a Feather (BOF)
meeting, as described below, to gage the level of support for a meeting, as described below, to gage the level of support for a
working group before submitting the charter to the IESG and IAB for working group before submitting the charter to the IESG and IAB for
approval. approval.
Charters may be renegotiated periodically to reflect the current Charters may be renegotiated periodically to reflect the current
status, organization or goals of the working group (see section 5). status, organization or goals of the working group (see Section 6).
Hence, a charter is a contract between the IETF and the working group Hence, a charter is a contract between the IETF and the working group
which is committing to meet explicit milestones and delivering which is committing to a scope for the work and optionally also to
specific "products". meet explicit milestones and delivering specific "products".
Specifically, each charter consists of the following sections: Specifically, each charter consists of the following sections:
Working group name Working group name A working group name should be reasonably
A working group name should be reasonably descriptive or descriptive or identifiable. Additionally, the group shall define
identifiable. Additionally, the group shall define an acronym an acronym (maximum 8 printable ASCII characters) to reference the
(maximum 8 printable ASCII characters) to reference the group in group in the IETF directories, mailing lists, and general
the IETF directories, mailing lists, and general documents. documents.
Chair(s) Chair(s) The working group may have one or more Chairs to perform
The working group may have one or more Chairs to perform the the administrative functions of the group. The email address(es)
administrative functions of the group. The email address(es) of of the Chair(s) shall be included. Generally, a working group is
the Chair(s) shall be included. Generally, a working group is
limited to two chairs. limited to two chairs.
Area and Area Director(s) Area and Area Director(s) The name of the IETF area with which the
The name of the IETF area with which the working group is working group is affiliated and the name and electronic mail
affiliated and the name and electronic mail address of the address of the associated Area Director(s).
associated Area Director(s).
Responsible Area Director Responsible Area Director The Area Director who acts as the primary
The Area Director who acts as the primary IESG contact for the IESG contact for the working group.
working group.
Mailing list Mailing list An IETF working group MUST have a general Internet
An IETF working group MUST have a general Internet mailing list. mailing list. Most of the work of an IETF working group will be
Most of the work of an IETF working group will be conducted on the conducted on the mailing list. The working group charter MUST
mailing list. The working group charter MUST include: include:
1. The address to which a participant sends a subscription request 1. The address to which a participant sends a subscription request
and the procedures to follow when subscribing, and the procedures to follow when subscribing,
2. The address to which a participant sends submissions and 2. The address to which a participant sends submissions and special
special procedures, if any, and procedures, if any, and
3. The location of the mailing list archive. A message archive 3. The location of the mailing list archive. A message archive MUST
MUST be maintained in a public place which can be accessed via be maintained in a public place which can be accessed via the
FTP or via the web. web.
As a service to the community, the IETF Secretariat operates a Description of working group The focus and intent of the group shall
mailing list archive for working group mailing lists. In order be set forth briefly. By reading this section alone, an
to take advantage of this service, working group mailing lists individual should be able to decide whether this group is relevant
MUST include the address "wg_acronym-archive@lists.ietf.org" to their own work. The first paragraph must give a brief summary
(where "wg_acronym" is the working group acronym) in the of the problem area, basis, goal(s) and approach(es) planned for
mailing list in order that a copy of all mailing list messages the working group. This paragraph can be used as an overview of
be recorded in the Secretariat's archive. Those archives are the working group's effort.
located at ftp://ftp.ietf.org/ietf-mail-archive. For
robustness, WGs SHOULD maintain an additional archive separate
from that maintained by the Secretariat.
Description of working group To facilitate evaluation of the intended work and to provide on-going
The focus and intent of the group shall be set forth briefly. By guidance to the working group, the charter must describe the problem
reading this section alone, an individual should be able to decide being solved and should discuss objectives and expected impact with
whether this group is relevant to their own work. The first respect to:
paragraph must give a brief summary of the problem area, basis,
goal(s) and approach(es) planned for the working group. This
paragraph can be used as an overview of the working group's
effort.
To facilitate evaluation of the intended work and to provide on- * Architecture
going guidance to the working group, the charter must describe the
problem being solved and should discuss objectives and expected
impact with respect to:
- Architecture * Operations
- Operations * Security
- Security
- Network management
- Scaling
- Transition (where applicable)
Goals and milestones * Network management
The working group charter MUST establish a timetable for specific
work items. While this may be renegotiated over time, the list of
milestones and dates facilitates the Area Director's tracking of
working group progress and status, and it is indispensable to
potential participants identifying the critical moments for input.
Milestones shall consist of deliverables that can be qualified as
showing specific achievement; e.g., "Internet-Draft finished" is
fine, but "discuss via email" is not. It is helpful to specify
milestones for every 3-6 months, so that progress can be gauged
easily. This milestone list is expected to be updated
periodically (see section 5).
An example of a WG charter is included as Appendix A. * Scaling
2.3. Charter review & approval * Transition (where applicable)
Goals and milestones The working group charter SHOULD establish a
timetable for specific work items. While this may be renegotiated
over time, the list of milestones and dates facilitates the Area
Director's tracking of working group progress and status, and it
can facilitate potential participants identifying the critical
moments for input. Milestones shall consist of deliverables that
can be qualified as showing specific achievement; e.g., "Internet-
Draft finished" is fine, but "discuss via email" is not. It is
helpful to specify milestones for every 3-6 months, so that
progress can be gauged easily. This milestone list is expected to
be updated periodically (see Section 6).
3.3. Charter review & approval
Proposed working groups often comprise technically competent Proposed working groups often comprise technically competent
participants who are not familiar with the history of Internet participants who are not familiar with the history of Internet
architecture or IETF processes. This can, unfortunately, lead to architecture or IETF processes. This can, unfortunately, lead to
good working group consensus about a bad design. To facilitate good working group consensus about a bad design. To facilitate
working group efforts, an Area Director may assign a Consultant from working group efforts, an Area Director may assign a Consultant from
among the ranks of senior IETF participants. (Consultants are among the ranks of senior IETF participants. (Consultants are
described in section 6.) At the discretion of the Area Director, described in Section 7.6.) At the discretion of the Area Director,
approval of a new WG may be withheld in the absence of sufficient approval of a new WG may be withheld in the absence of sufficient
consultant resources. consultant resources.
Once the Area Director (and the Area Directorate, as the Area Once the Area Director (and the Area Directorate, as the Area
Director deems appropriate) has approved the working group charter, Director deems appropriate) has approved the working group charter,
the charter is submitted for review by the IAB and approval by the the charter is submitted for review by the IAB and approval by the
IESG. After a review period of at least a week the proposed charter IESG. After a review period of at least a week the proposed charter
is posted to the IETF-announce mailing list as a public notice that is posted to the IETF-announce mailing list as a public notice that
the formation of the working group is being considered. At the same the formation of the working group is being considered. At the same
time the proposed charter is also posted to the "new-work" mailing time the proposed charter is also posted to the "new-work" mailing
skipping to change at page 9, line 10 skipping to change at page 10, line 4
IESG. After a review period of at least a week the proposed charter IESG. After a review period of at least a week the proposed charter
is posted to the IETF-announce mailing list as a public notice that is posted to the IETF-announce mailing list as a public notice that
the formation of the working group is being considered. At the same the formation of the working group is being considered. At the same
time the proposed charter is also posted to the "new-work" mailing time the proposed charter is also posted to the "new-work" mailing
list. This mailing list has been created to let qualified list. This mailing list has been created to let qualified
representatives from other standards organizations know about pending representatives from other standards organizations know about pending
IETF working groups. After another review period lasting at least a IETF working groups. After another review period lasting at least a
week the IESG MAY approve the charter as-is, it MAY request that week the IESG MAY approve the charter as-is, it MAY request that
changes be made in the charter, or MAY decline to approve chartering changes be made in the charter, or MAY decline to approve chartering
of the working group of the working group
If the IESG approves the formation of the working group it remands If the IESG approves the formation of the working group it remands
the approved charter to the IETF Secretariat who records and enters the approved charter to the IETF Secretariat who records and enters
the information into the IETF tracking database. The working group the information into the IETF tracking database. The working group
is announced to the IETF-announce a by the IETF Secretariat. is announced to the IETF-announce a by the IETF Secretariat.
2.4. Birds of a Feather (BOF) While chartering a new working group, the IESG will decide whether
milestones are initially enabled or disabled for this working group,
and if enabled whether there are dates included, and at what
granularity. Examples of granularity include months, quarters, half-
years, IETF meetings, and sooner-vs-later. The responsible Area
Director is empowered to change these details without formal updates
to the charter. The Area Director is encouraged to discuss these
choices with the working group chairs, as the success of milestones
is predicated on the chairs updating them in a timely manner.
Updating the date attached to a milestone is under the authority of
the working group chairs and does not require pre-approval of the
Area Director. However, in the case of a disagreement the final
decision lies with the Area Director.
3.4. Birds of a Feather (BOF)
Often it is not clear whether an issue merits the formation of a Often it is not clear whether an issue merits the formation of a
working group. To facilitate exploration of the issues the IETF working group. To facilitate exploration of the issues the IETF
offers the possibility of a Birds of a Feather (BOF) session, as well offers the possibility of a Birds of a Feather (BOF) session, as well
as the early formation of an email list for preliminary discussion. as the early formation of an email list for preliminary discussion.
In addition, a BOF may serve as a forum for a single presentation or In addition, a BOF may serve as a forum for a single presentation or
discussion, without any intent to form a working group. discussion, without any intent to form a working group.
A BOF is a session at an IETF meeting which permits "market research" A BOF is a session at an IETF meeting which permits "market research"
and technical "brainstorming". Any individual may request permission and technical "brainstorming". Any individual may request permission
to hold a BOF on a subject. The request MUST be filed with a relevant to hold a BOF on a subject. The request MUST be filed with a
Area Director who must approve a BOF before it can be scheduled. The relevant Area Director who must approve a BOF before it can be
person who requests the BOF may be asked to serve as Chair of the scheduled. The person who requests the BOF may be asked to serve as
BOF. Chair of the BOF.
The Chair of the BOF is also responsible for providing a report on The Chair of the BOF is also responsible for providing a report on
the outcome of the BOF. If the Area Director approves, the BOF is the outcome of the BOF. If the Area Director approves, the BOF is
then scheduled by submitting a request to agenda@ietf.org with copies then scheduled by submitting a request to agenda@ietf.org with copies
to the Area Director(s). A BOF description and agenda are required to the Area Director(s). A BOF description and agenda are required
before a BOF can be scheduled. before a BOF can be scheduled.
Available time for BOFs is limited, and BOFs are held at the Available time for BOFs is limited, and BOFs are held at the
discretion of the ADs for an area. The AD(s) may require additional discretion of the ADs for an area. The AD(s) may require additional
assurances before authorizing a BOF. For example, assurances before authorizing a BOF. For example,
* The Area Director MAY require the establishment of an open email
- The Area Director MAY require the establishment of an open email
list prior to authorizing a BOF. This permits initial exchanges list prior to authorizing a BOF. This permits initial exchanges
and sharing of framework, vocabulary and approaches, in order to and sharing of framework, vocabulary and approaches, in order to
make the time spent in the BOF more productive. make the time spent in the BOF more productive.
- The Area Director MAY require that a BOF be held, prior to * The Area Director MAY require that a BOF be held, prior to
establishing a working group (see section 2.2). establishing a working group (see Section 3.2).
- The Area Director MAY require that there be a draft of the WG * The Area Director MAY require that there be a draft of the WG
charter prior to holding a BOF. charter prior to holding a BOF.
- The Area Director MAY require that a BOF not be held until an * The Area Director MAY require that a BOF not be held until an
Internet-Draft describing the proposed technology has been Internet-Draft describing the proposed technology has been
published so it can be used as a basis for discussion in the BOF. published so it can be used as a basis for discussion in the BOF.
In general, a BOF on a particular topic is held only once (ONE slot In general, a BOF on a particular topic is held only once (ONE slot
at one IETF Plenary meeting). Under unusual circumstances Area at one IETF Plenary meeting). Under unusual circumstances Area
Directors may, at their discretion, allow a BOF to meet for a second Directors may, at their discretion, allow a BOF to meet for a second
time. BOFs are not permitted to meet three times. Note that all time. BOFs are not permitted to meet three times. Note that all
other things being equal, WGs will be given priority for meeting other things being equal, WGs will be given priority for meeting
space over BOFs. Also, occasionally BOFs may be held for other space over BOFs. Also, occasionally BOFs may be held for other
purposes than to discuss formation of a working group. purposes than to discuss formation of a working group.
Usually the outcome of a BOF will be one of the following: Usually the outcome of a BOF will be one of the following:
- There was enough interest and focus in the subject to warrant the * There was enough interest and focus in the subject to warrant the
formation of a WG; formation of a WG;
- While there was a reasonable level of interest expressed in the * While there was a reasonable level of interest expressed in the
BOF some other criteria for working group formation was not met BOF some other criteria for working group formation was not met
(see section 2.1). (see Section 3.1).
- The discussion came to a fruitful conclusion, with results to be * The discussion came to a fruitful conclusion, with results to be
written down and published, however there is no need to establish written down and published, however there is no need to establish
a WG; or a WG; or
- There was not enough interest in the subject to warrant the * There was not enough interest in the subject to warrant the
formation of a WG. formation of a WG.
3. Working Group Operation 4. Working Group Operation
The IETF has basic requirements for open and fair participation and The IETF has basic requirements for open and fair participation and
for thorough consideration of technical alternatives. Within those for thorough consideration of technical alternatives. Within those
constraints, working groups are autonomous and each determines most constraints, working groups are autonomous and each determines most
of the details of its own operation with respect to session of the details of its own operation with respect to session
participation, reaching closure, etc. The core rule for operation is participation, reaching closure, etc. The core rule for operation is
that acceptance or agreement is achieved via working group "rough that acceptance or agreement is achieved via working group "rough
consensus". WG participants should specifically note the consensus". WG participants should specifically note the
requirements for disclosure of conflicts of interest in [2]. requirements around intellectual property in [_2026bis].
A number of procedural questions and issues will arise over time, and A number of procedural questions and issues will arise over time, and
it is the function of the Working Group Chair(s) to manage the group it is the function of the Working Group Chair(s) to manage the group
process, keeping in mind that the overall purpose of the group is to process, keeping in mind that the overall purpose of the group is to
make progress towards reaching rough consensus in realizing the make progress towards reaching rough consensus in realizing the
working group's goals and objectives. working group's goals and objectives.
There are few hard and fast rules on organizing or conducting working There are few hard and fast rules on organizing or conducting working
group activities, but a set of guidelines and practices has evolved group activities, but a set of guidelines and practices has evolved
over time that have proven successful. These are listed here, with over time that have proven successful. These are listed here, with
actual choices typically determined by the working group participants actual choices typically determined by the working group participants
and the Chair(s). and the Chair(s).
3.1. Session planning 4.1. Session planning
For coordinated, structured WG interactions, the Chair(s) MUST For coordinated, structured WG interactions, the Chair(s) MUST
publish a draft agenda well in advance of the actual session. The publish a draft agenda well in advance of the actual session. The
agenda should contain at least: agenda should contain at least:
- The items for discussion; * The items for discussion;
- The estimated time necessary per item; and
- A clear indication of what documents the participants will need to * The estimated time necessary per item; and
read before the session in order to be well prepared.
* A clear indication of what documents the participants will need to
read before the session in order to be well prepared.
Publication of the working group agenda shall include sending a copy Publication of the working group agenda shall include sending a copy
of the agenda to the working group mailing list and to of the agenda to the working group mailing list and to
agenda@ietf.org. agenda@ietf.org.
All working group actions shall be taken in a public forum, and wide All working group actions shall be taken in a public forum, and wide
participation is encouraged. A working group will conduct much of its participation is encouraged. A working group will conduct much of
business via electronic mail distribution lists but may meet its business via electronic mail distribution lists but may meet
periodically to discuss and review task status and progress, to periodically to discuss and review task status and progress, to
resolve specific issues and to direct future activities. IETF resolve specific issues and to direct future activities. IETF
Plenary meetings are the primary venue for these face-to-face working Plenary meetings are the primary venue for these face-to-face working
group sessions, and it is common (though not required) that active group sessions, and it is common (though not required) that active
"interim" face-to-face meetings, telephone conferences, or video "interim" face-to-face meetings, telephone conferences, or video
conferences may also be held. Interim meetings are subject to the conferences may also be held. Interim meetings are subject to the
same rules for advance notification, reporting, open participation, same rules for advance notification, reporting, open participation,
and process, which apply to other working group meetings. and process, which apply to other working group meetings.
All working group sessions (including those held outside of the IETF All working group sessions (including those held outside of the IETF
meetings) shall be reported by making minutes available. These meetings) shall be reported by making minutes available. These
minutes should include the agenda for the session, an account of the minutes should include the agenda for the session, an account of the
discussion including any decisions made, and a list of attendees. The discussion including any decisions made, and a list of attendees.
Working Group Chair is responsible for insuring that session minutes The Working Group Chair is responsible for insuring that session
are written and distributed, though the actual task may be performed minutes are written and distributed, though the actual task may be
by someone designated by the Working Group Chair. The minutes shall performed by someone designated by the Working Group Chair. The
be submitted in printable ASCII text for publication in the IETF minutes shall be submitted in printable ASCII text for publication in
Proceedings, and for posting in the IETF Directories and are to be the IETF Proceedings, and for posting in the IETF Directories and are
sent to: minutes@ietf.org to be sent to: minutes@ietf.org
3.2. Session venue 4.2. Session venue
Each working group will determine the balance of email and face-to- Each working group will determine the balance of email and face-to-
face sessions that is appropriate for achieving its milestones. face sessions that is appropriate for achieving its goals.
Electronic mail permits the widest participation; face-to-face Electronic mail permits the widest participation; face-to-face
meetings often permit better focus and therefore can be more meetings often permit better focus and therefore can be more
efficient for reaching a consensus among a core of the working group efficient for reaching a consensus among a core of the working group
participants. In determining the balance, the WG must ensure that participants. In determining the balance, the WG must ensure that
its process does not serve to exclude contribution by email-only its process does not serve to exclude contribution by email-only
participants. Decisions reached during a face-to-face meeting about participants. Decisions reached during a face-to-face meeting about
topics or issues which have not been discussed on the mailing list, topics or issues which have not been discussed on the mailing list,
or are significantly different from previously arrived mailing list or are significantly different from previously arrived mailing list
consensus MUST be reviewed on the mailing list. consensus MUST be reviewed on the mailing list.
IETF Meetings 4.2.1. IETF Meetings
If a WG needs a session at an IETF meeting, the Chair must apply for If a WG needs a session at an IETF meeting, the Chair must apply for
time-slots as soon as the first announcement of that IETF meeting is time-slots as soon as the first announcement of that IETF meeting is
made by the IETF Secretariat to the WG-chairs list. Session time is made by the IETF Secretariat to the WG-chairs list. Session time is
a scarce resource at IETF meetings, so placing requests early will a scarce resource at IETF meetings, so placing requests early will
facilitate schedule coordination for WGs requiring the same set of facilitate schedule coordination for WGs requiring the same set of
experts. experts.
The application for a WG session at an IETF meeting MUST be made to The application for a WG session at an IETF meeting MUST be made to
the IETF Secretariat at the address agenda@ietf.org. Some Area the IETF Secretariat at the address agenda@ietf.org. Some Area
Directors may want to coordinate WG sessions in their area and Directors may want to coordinate WG sessions in their area and
request that time slots be coordinated through them. If this is the request that time slots be coordinated through them. If this is the
case it will be noted in the IETF meeting announcement. A WG case it will be noted in the IETF meeting announcement. A WG
scheduling request MUST contain: scheduling request MUST contain:
- The working group name and full title; * The working group name and full title;
- The amount of time requested;
- The rough outline of the WG agenda that is expected to be covered; * The amount of time requested;
- The estimated number of people that will attend the WG session;
- Related WGs that should not be scheduled for the same time slot(s); * The rough outline of the WG agenda that is expected to be covered;
and
- Optionally a request can be added for the WG session to be * The estimated number of people that will attend the WG session;
transmitted over the Internet in audio and video.
* Related WGs that should not be scheduled for the same time
slot(s); and
* Optionally a request can be added for the WG session to be
transmitted over the Internet in audio and video.
NOTE: While open discussion and contribution is essential to working NOTE: While open discussion and contribution is essential to working
group success, the Chair is responsible for ensuring forward group success, the Chair is responsible for ensuring forward
progress. When acceptable to the WG, the Chair may call for progress. When acceptable to the WG, the Chair may call for
restricted participation (but not restricted attendance!) at IETF restricted participation (but not restricted attendance!) at IETF
working group sessions for the purpose of achieving progress. The working group sessions for the purpose of achieving progress. The
Working Group Chair then has the authority to refuse to grant the Working Group Chair then has the authority to refuse to grant the
floor to any individual who is unprepared or otherwise covering floor to any individual who is unprepared or otherwise covering
inappropriate material, or who, in the opinion of the Chair is inappropriate material, or who, in the opinion of the Chair is
disrupting the WG process. The Chair should consult with the Area disrupting the WG process. The Chair should consult with the Area
Director(s) if the individual persists in disruptive behavior. Director(s) if the individual persists in disruptive behavior.
On-line For working groups where milestones are enabled, chairs are expected
to keep milestones up to date. Chairs are expected to review
milestones at least once per IETF meeting (every four months) to
ensure they are accurate.
4.2.2. On-line
It can be quite useful to conduct email exchanges in the same manner It can be quite useful to conduct email exchanges in the same manner
as a face-to-face session, with published schedule and agenda, as as a face-to-face session, with published schedule and agenda, as
well as on-going summarization and consensus polling. well as on-going summarization and consensus polling.
Many working group participants hold that mailing list discussion is Many working group participants hold that mailing list discussion is
the best place to consider and resolve issues and make decisions. The the best place to consider and resolve issues and make decisions.
choice of operational style is made by the working group itself. It The choice of operational style is made by the working group itself.
is important to note, however, that Internet email discussion is It is important to note, however, that Internet email discussion is
possible for a much wider base of interested persons than is possible for a much wider base of interested persons than is
attendance at IETF meetings, due to the time and expense required to attendance at IETF meetings, due to the time and expense required to
attend. attend.
As with face-to-face sessions occasionally one or more individuals As in face-to-face sessions, occasionally one or more individuals may
may engage in behavior on a mailing list which disrupts the WG's engage in behavior on a mailing list that, in the opinion of the WG
progress. In these cases the Chair should attempt to discourage the chair, is disruptive to the WG process. Unless the disruptive
behavior by communication directly with the offending individual behavior is severe enough that it must be stopped immediately, the WG
rather than on the open mailing list. If the behavior persists then chair should attempt to discourage the disruptive behavior by
the Chair must involve the Area Director in the issue. As a last communicating directly with the offending individual. If the
resort and after explicit warnings, the Area Director, with the behavior persists, the WG chair should send at least one public
approval of the IESG, may request that the mailing list maintainer warning on the WG mailing list. As a last resort and typically after
block the ability of the offending individual to post to the mailing one or more explicit warnings and consultation with the responsible
list. (If the mailing list software permits this type of operation.) Area Director, the WG chair may suspend the mailing list posting
Even if this is done, the individual must not be prevented from privileges of the disruptive individual for a period of not more than
receiving messages posted to the list. Other methods of mailing list 30 days. Even while posting privileges are suspended, the individual
control may be considered but must be approved by the AD(s) and the must not be prevented from receiving messages posted to the list.
IESG. Like all other WG chair decisions, any suspension of posting
privileges is subject to appeal, as described in [_2026bis].
3.3. Session management This mechanism is intended to permit a WG chair to suspend posting
privileges of a disruptive individual for a short period of time.
This mechanism does not permit WG chairs to suspend an individual's
posting privileges for a period longer than 30 days regardless of the
type or severity of the disruptive incident. However, further
disruptive behavior by the same individual will be considered
separately and may result in further warnings or suspensions. Other
methods of mailing list control, including longer suspensions, must
be carried out in accordance with other IETF-approved procedures.
See [RFC3683] for one set of procedures already defined and accepted
by the community.
4.3. Session management
Working groups make decisions through a "rough consensus" process. Working groups make decisions through a "rough consensus" process.
IETF consensus does not require that all participants agree although IETF consensus does not require that all participants agree although
this is, of course, preferred. In general, the dominant view of the this is, of course, preferred. In general, the dominant view of the
working group shall prevail. (However, it must be noted that working group shall prevail. (However, it must be noted that
"dominance" is not to be determined on the basis of volume or "dominance" is not to be determined on the basis of volume or
persistence, but rather a more general sense of agreement.) Consensus persistence, but rather a more general sense of agreement.)
can be determined by a show of hands, humming, or any other means on Consensus can be determined by a show of hands, humming, or any other
which the WG agrees (by rough consensus, of course). Note that 51% means on which the WG agrees (by rough consensus, of course). Note
of the working group does not qualify as "rough consensus" and 99% is that 51% of the working group does not qualify as "rough consensus"
better than rough. It is up to the Chair to determine if rough and 99% is better than rough. It is up to the Chair to determine if
consensus has been reached. rough consensus has been reached.
It can be particularly challenging to gauge the level of consensus on It can be particularly challenging to gauge the level of consensus on
a mailing list. There are two different cases where a working group a mailing list. There are two different cases where a working group
may be trying to understand the level of consensus via a mailing list may be trying to understand the level of consensus via a mailing list
discussion. But in both cases the volume of messages on a topic is discussion. But in both cases the volume of messages on a topic is
not, by itself, a good indicator of consensus since one or two not, by itself, a good indicator of consensus since one or two
individuals may be generating much of the traffic. individuals may be generating much of the traffic.
In the case where a consensus which has been reached during a face- In the case where a consensus which has been reached during a face-
to-face meeting is being verified on a mailing list the people who to-face meeting is being verified on a mailing list the people who
were in the meeting and expressed agreement must be taken into were in the meeting and expressed agreement must be taken into
account. If there were 100 people in a meeting and only a few people account. If there were 100 people in a meeting and only a few people
on the mailing list disagree with the consensus of the meeting then on the mailing list disagree with the consensus of the meeting then
the consensus should be seen as being verified. Note that enough the consensus should be seen as being verified. Note that enough
time should be given to the verification process for the mailing list time should be given to the verification process for the mailing list
readers to understand and consider any objections that may be raised readers to understand and consider any objections that may be raised
on the list. The normal two week last-call period should be on the list. The normal two week last-call period should be
sufficient for this. sufficient for this.
The other case is where the discussion has been held entirely over The other case is where the discussion has been held entirely over
the mailing list. The determination of the level of consensus may be the mailing list. The determination of the level of consensus may be
harder to do in this case since most people subscribed to mailing harder to do in this case since most people subscribed to mailing
lists do not actively participate in discussions on the list. It is lists do not actively participate in discussions on the list. It is
left to the discretion of the working group chair how to evaluate the left to the discretion of the working group chair how to evaluate the
level of consensus. The most common method used is for the working level of consensus. The most common method used is for the working
group chair to state what he or she believes to be the consensus view group chair to state what he or she believes to be the consensus view
and. at the same time, requests comments from the list about the and. at the same time, requests comments from the list about the
stated conclusion. stated conclusion.
The challenge to managing working group sessions is to balance the The challenge to managing working group sessions is to balance the
need for open and fair consideration of the issues against the need need for open and fair consideration of the issues against the need
to make forward progress. The working group, as a whole, has the to make forward progress. The working group, as a whole, has the
final responsibility for striking this balance. The Chair has the final responsibility for striking this balance. The Chair has the
responsibility for overseeing the process but may delegate direct responsibility for overseeing the process but may delegate direct
process management to a formally-designated Facilitator. process management to a formally-designated Facilitator.
It is occasionally appropriate to revisit a topic, to re-evaluate It is occasionally appropriate to revisit a topic, to re-evaluate
alternatives or to improve the group's understanding of a relevant alternatives or to improve the group's understanding of a relevant
decision. However, unnecessary repeated discussions on issues can be decision. However, unnecessary repeated discussions on issues can be
avoided if the Chair makes sure that the main arguments in the avoided if the Chair makes sure that the main arguments in the
discussion (and the outcome) are summarized and archived after a discussion (and the outcome) are summarized and archived after a
discussion has come to conclusion. It is also good practice to note discussion has come to conclusion. It is also good practice to note
important decisions/consensus reached by email in the minutes of the important decisions/consensus reached by email in the minutes of the
next 'live' session, and to summarize briefly the decision-making next 'live' session, and to summarize briefly the decision-making
history in the final documents the WG produces. history in the final documents the WG produces.
To facilitate making forward progress, a Working Group Chair may wish To facilitate making forward progress, a Working Group Chair may wish
to decide to reject or defer the input from a member, based upon the to decide to reject or defer the input from a member, based upon the
following criteria: following criteria:
Old Old The input pertains to a topic that already has been resolved and
The input pertains to a topic that already has been resolved and is is redundant with information previously available;
redundant with information previously available;
Minor Minor The input is new and pertains to a topic that has already been
The input is new and pertains to a topic that has already been resolved, but it is felt to be of minor import to the existing
resolved, but it is felt to be of minor import to the existing decision;
decision;
Timing
The input pertains to a topic that the working group has not yet
opened for discussion; or
Scope Timing The input pertains to a topic that the working group has not
The input is outside of the scope of the working group charter. yet opened for discussion; or
3.4. Contention and appeals Scope The input is outside of the scope of the working group
charter.
Disputes are possible at various stages during the IETF process. As 4.4. Contention and appeals
Disputes are possible at various stages during the IETF process. As
much as possible the process is designed so that compromises can be much as possible the process is designed so that compromises can be
made, and genuine consensus achieved; however, there are times when made, and genuine consensus achieved; however, there are times when
even the most reasonable and knowledgeable people are unable to even the most reasonable and knowledgeable people are unable to
agree. To achieve the goals of openness and fairness, such conflicts agree. To achieve the goals of openness and fairness, such conflicts
must be resolved by a process of open review and discussion. must be resolved by a process of open review and discussion.
Formal procedures for requesting a review of WG, Chair, Area Director Formal procedures for requesting a review of WG, Chair, Area Director
or IESG actions and conducting appeals are documented in The Internet or IESG actions and conducting appeals are documented in The Internet
Standards Process [1]. Standards Process [_2026bis].
4. Working Group Termination 5. Working Group Termination
Working groups are typically chartered to accomplish a specific task Working groups are typically chartered to accomplish a specific task
or tasks. After the tasks are complete, the group will be disbanded. or tasks. After the tasks are complete, the group will be disbanded.
However, if a WG produces a Proposed or Draft Standard, the WG will However, if a WG produces a Proposed or Draft Standard, the WG will
frequently become dormant rather than disband (i.e., the WG will no frequently become dormant rather than disband (i.e., the WG will no
longer conduct formal activities, but the mailing list will remain longer conduct formal activities, but the mailing list will remain
available to review the work as it moves to Draft Standard and available to review the work as it moves to Draft Standard and
Standard status.) Standard status.)
If, at some point, it becomes evident that a working group is unable If, at some point, it becomes evident that a working group is unable
to complete the work outlined in the charter, or if the assumptions to complete the work outlined in the charter, or if the assumptions
which that work was based have been modified in discussion or by which that work was based have been modified in discussion or by
experience, the Area Director, in consultation with the working group experience, the Area Director, in consultation with the working group
can either: can either:
1. Recharter to refocus its tasks, 1. Recharter to refocus its tasks,
2. Choose new Chair(s), or
3. Disband. 2. Choose new Chair(s), or
3. Disband.
If the working group disagrees with the Area Director's choice, it If the working group disagrees with the Area Director's choice, it
may appeal to the IESG (see section 3.4). may appeal to the IESG (see Section 4.4).
5. Rechartering a Working Group 6. Rechartering a Working Group
Updated milestones are renegotiated with the Area Director and the Updated milestones are renegotiated with the Area Director and the
IESG, as needed, and then are submitted to the IESG Secretariat: IESG, as needed, and then are submitted to the IESG Secretariat:
iesg-secretary@ietf.org. iesg-secretary@ietf.org. Similarly, the Area Director can enable or
disable milestones, or enable or disable dates, or change the
granularity of dates, all without a formal recharter.
Rechartering (other than revising milestones) a working group follows Rechartering (other than changes to milestones) a working group
the same procedures that the initial chartering does (see section 2). follows the same procedures that the initial chartering does (see
The revised charter must be submitted to the IESG and IAB for Section 3). The revised charter must be submitted to the IESG and
approval. As with the initial chartering, the IESG may approve new IAB for approval. As with the initial chartering, the IESG may
charter as-is, it may request that changes be made in the new charter approve new charter as-is, it may request that changes be made in the
(including having the Working Group continue to use the old charter), new charter (including having the Working Group continue to use the
or it may decline to approve the rechartered working group. In the old charter), or it may decline to approve the rechartered working
latter case, the working group is disbanded. group. In the latter case, the working group is disbanded.
6. Staff Roles 7. Staff Roles
Working groups require considerable care and feeding. In addition to Working groups require considerable care and feeding. In addition to
general participation, successful working groups benefit from the general participation, successful working groups benefit from the
efforts of participants filling specific functional roles. The Area efforts of participants filling specific functional roles. The Area
Director must agree to the specific people performing the WG Chair, Director must agree to the specific people performing the WG Chair,
and Working Group Consultant roles, and they serve at the discretion and Working Group Consultant roles, and they serve at the discretion
of the Area Director. of the Area Director.
6.1. WG Chair 7.1. WG Chair
The Working Group Chair is concerned with making forward progress The Working Group Chair is concerned with making forward progress
through a fair and open process, and has wide discretion in the through a fair and open process, and has wide discretion in the
conduct of WG business. The Chair must ensure that a number of tasks conduct of WG business. The Chair must ensure that a number of tasks
are performed, either directly or by others assigned to the tasks. are performed, either directly or by others assigned to the tasks.
The Chair has the responsibility and the authority to make decisions, The Chair has the responsibility and the authority to make decisions,
on behalf of the working group, regarding all matters of working on behalf of the working group, regarding all matters of working
group process and staffing, in conformance with the rules of the group process and staffing, in conformance with the rules of the
IETF. The AD has the authority and the responsibility to assist in IETF. The AD has the authority and the responsibility to assist in
making those decisions at the request of the Chair or when making those decisions at the request of the Chair or when
circumstances warrant such an intervention. circumstances warrant such an intervention.
The Chair's responsibility encompasses at least the following: The Chair's responsibility encompasses at least the following:
Ensure WG process and content management * Ensure WG process and content management
The Chair has ultimate responsibility for ensuring that a working
group achieves forward progress and meets its milestones. The
Chair is also responsible to ensure that the working group
operates in an open and fair manner. For some working groups,
this can be accomplished by having the Chair perform all
management-related activities. In other working groups --
particularly those with large or divisive participation -- it is
helpful to allocate process and/or secretarial functions to other
participants. Process management pertains strictly to the style
of working group interaction and not to its content. It ensures
fairness and detects redundancy. The secretarial function
encompasses document editing. It is quite common for a working
group to assign the task of specification Editor to one or two
participants. Sometimes, they also are part of the design team,
described below.
Moderate the WG email list The Chair has ultimate responsibility for ensuring that a working
group achieves forward progress and meets its goals. The Chair is
also responsible to ensure that the working group operates in an open
and fair manner. For some working groups, this can be accomplished
by having the Chair perform all management-related activities. In
other working groups -- particularly those with large or divisive
participation -- it is helpful to allocate process and/or secretarial
functions to other participants. Process management pertains
strictly to the style of working group interaction and not to its
content. It ensures fairness and detects redundancy. The
secretarial function encompasses document editing. It is quite
common for a working group to assign the task of specification Editor
to one or two participants. Sometimes, they also are part of the
design team, described below.
The Chair should attempt to ensure that the discussions on this * Moderate the WG email list
list are relevant and that they converge to consensus agreements.
The Chair should make sure that discussions on the list are
summarized and that the outcome is well documented (to avoid
repetition). The Chair also may choose to schedule organized on-
line "sessions" with agenda and deliverables. These can be
structured as true meetings, conducted over the course of several
days (to allow participation across the Internet).
Organize, prepare and chair face-to-face and on-line formal The Chair should attempt to ensure that the discussions on this list
sessions. are relevant and that they converge to consensus agreements. The
Chair should make sure that discussions on the list are summarized
and that the outcome is well documented (to avoid repetition). They
may need to consult with the Ombudsteam (see Section 7.8) if they
feel harassment is involved. The Chair also may choose to schedule
organized on-line "sessions" with agenda and deliverables. These can
be structured as true meetings, conducted over the course of several
days (to allow participation across the Internet).
Plan WG Sessions Organize, prepare and chair face-to-face and on-line formal sessions.
The Chair must plan and announce all WG sessions well in advance * Plan WG Sessions
(see section 3.1).
Communicate results of sessions The Chair must plan and announce all WG sessions well in advance (see
Section 4.1).
The Chair and/or Secretary must ensure that minutes of a session * Communicate results of sessions
are taken and that an attendance list is circulated (see section
3.1).
Immediately after a session, the WG Chair MUST provide the Area The Chair and/or Secretary must ensure that minutes of a session are
Director with a very short report (approximately one paragraph, taken and that an attendance list is circulated (see Section 4.1).
via email) on the session.
Distribute the workload Immediately after a session, the WG Chair MUST provide the Area
Director with a very short report (approximately one paragraph, via
email) on the session.
Of course, each WG will have participants who may not be able (or * Distribute the workload
want) to do any work at all. Most of the time the bulk of the work
is done by a few dedicated participants. It is the task of the
Chair to motivate enough experts to allow for a fair distribution
of the workload.
Document development Of course, each WG will have participants who may not be able (or
want) to do any work at all. Most of the time the bulk of the work
is done by a few dedicated participants. It is the task of the Chair
to motivate enough experts to allow for a fair distribution of the
workload.
Working groups produce documents and documents need authors. The * Document development
Chair must make sure that authors of WG documents incorporate
changes as agreed to by the WG (see section 6.3).
Document publication Working groups produce documents and documents need authors. The
Chair must make sure that authors of WG documents incorporate changes
as agreed to by the WG (see Section 7.3).
The Chair and/or Document Editor will work with the RFC Editor to * Document publication
ensure document conformance with RFC publication requirements [5]
and to coordinate any editorial changes suggested by the RFC
Editor. A particular concern is that all participants are working
from the same version of a document at the same time.
Document implementations The Chair and/or Document Editor will work with the RFC Editor to
ensure document conformance with RFC publication requirements
[RFC7322] and to coordinate any editorial changes suggested by the
RFC Editor. A particular concern is that all participants are
working from the same version of a document at the same time.
Under the procedures described in [1], the Chair is responsible * Document implementations
for documenting the specific implementations which qualify the Under the procedures described in [_2026bis], the Chair is
specification for Draft or Internet Standard status along with responsible for documenting the specific implementations which
documentation about testing of the interoperation of these qualify the specification for Draft or Internet Standard status along
implementations. with documentation about testing of the interoperation of these
implementations.
6.2. WG Secretary 7.2. WG Secretary
Taking minutes and editing working group documents often is performed Taking minutes and editing working group documents often is performed
by a specifically-designated participant or set of participants. In by a specifically-designated participant or set of participants. In
this role, the Secretary's job is to record WG decisions, rather than this role, the Secretary's job is to record WG decisions, rather than
to perform basic specification. to perform basic specification.
6.3. Document Editor 7.3. Document Editor
Most IETF working groups focus their efforts on a document, or set of Most IETF working groups focus their efforts on a document, or set of
documents, that capture the results of the group's work. A working documents, that capture the results of the group's work. A working
group generally designates a person or persons to serve as the Editor group generally designates a person or persons to serve as the Editor
for a particular document. The Document Editor is responsible for for a particular document. The Document Editor is responsible for
ensuring that the contents of the document accurately reflect the ensuring that the contents of the document accurately reflect the
decisions that have been made by the working group. decisions that have been made by the working group.
As a general practice, the Working Group Chair and Document Editor As a general practice, the Working Group Chair and Document Editor
positions are filled by different individuals to help ensure that the positions are filled by different individuals to help ensure that the
resulting documents accurately reflect the consensus of the working resulting documents accurately reflect the consensus of the working
group and that all processes are followed. group and that all processes are followed.
6.4. WG Facilitator 7.4. WG Facilitator
When meetings tend to become distracted or divisive, it often is When meetings tend to become distracted or divisive, it often is
helpful to assign the task of "process management" to one helpful to assign the task of "process management" to one
participant. Their job is to oversee the nature, rather than the participant. Their job is to oversee the nature, rather than the
content, of participant interactions. That is, they attend to the content, of participant interactions. That is, they attend to the
style of the discussion and to the schedule of the agenda, rather style of the discussion and to the schedule of the agenda, rather
than making direct technical contributions themselves. than making direct technical contributions themselves. They may need
to consult with the Ombudsteam (see Section 7.8) if they feel
harassment is involved.
6.5. Design teams 7.5. Design teams
It is often useful, and perhaps inevitable, for a sub-group of a It is often useful, and perhaps inevitable, for a sub-group of a
working group to develop a proposal to solve a particular problem. working group to develop a proposal to solve a particular problem.
Such a sub-group is called a design team. In order for a design team Such a sub-group is called a design team. In order for a design team
to remain small and agile, it is acceptable to have closed membership to remain small and agile, it is acceptable to have closed membership
and private meetings. Design teams may range from an informal chat and private meetings. Design teams may range from an informal chat
between people in a hallway to a formal set of expert volunteers that between people in a hallway to a formal set of expert volunteers that
the WG chair or AD appoints to attack a controversial problem. The the WG chair or AD appoints to attack a controversial problem. The
output of a design team is always subject to approval, rejection or output of a design team is always subject to approval, rejection or
modification by the WG as a whole. modification by the WG as a whole.
6.6. Working Group Consultant 7.6. Working Group Consultant
At the discretion of the Area Director, a Consultant may be assigned At the discretion of the Area Director, a Consultant may be assigned
to a working group. Consultants have specific technical background to a working group. Consultants have specific technical background
appropriate to the WG and experience in Internet architecture and appropriate to the WG and experience in Internet architecture and
IETF process. IETF process.
6.7. Area Director 7.7. Area Director
Area Directors are responsible for ensuring that working groups in Area Directors are responsible for ensuring that working groups in
their area produce coherent, coordinated, architecturally consistent their area produce coherent, coordinated, architecturally consistent
and timely output as a contribution to the overall results of the and timely output as a contribution to the overall results of the
IETF. IETF.
7. Working Group Documents 7.8. Ombudsteam
7.1. Session documents As noted in [RFC7776]:
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.
The Ombudsteam is a resource for the entire IETF intended to address
issues of harassment, and all WG participants should feel free to
engage with the team if they feel there is an issue.
8. Working Group Documents
8.1. Session documents
All relevant documents to be discussed at a session should be All relevant documents to be discussed at a session should be
published and available as Internet-Drafts at least two weeks before published and available as Internet-Drafts at least two weeks before
a session starts. Any document which does not meet this publication a session starts. Any document which does not meet this publication
deadline can only be discussed in a working group session with the deadline can only be discussed in a working group session with the
specific approval of the working group chair(s). Since it is specific approval of the working group chair(s). Since it is
important that working group members have adequate time to review all important that working group members have adequate time to review all
documents, granting such an exception should only be done under documents, granting such an exception should only be done under
unusual conditions. The final session agenda should be posted to the unusual conditions. The final session agenda should be posted to the
working group mailing list at least two weeks before the session and working group mailing list at least two weeks before the session and
sent at that time to agenda@ietf.org for publication on the IETF web sent at that time to agenda@ietf.org for publication on the IETF web
site. site.
7.2. Internet-Drafts (I-D) 8.2. Internet-Drafts (I-D)
The Internet-Drafts directory is provided to working groups as a The Internet-Drafts directory is provided to working groups as a
resource for posting and disseminating in-process copies of working resource for posting and disseminating in-process copies of working
group documents. This repository is replicated at various locations group documents. This repository is replicated at various locations
around the Internet. It is encouraged that draft documents be posted around the Internet. It is encouraged that draft documents be posted
as soon as they become reasonably stable. as soon as they become reasonably stable.
It is stressed here that Internet-Drafts are working documents and It is stressed here that Internet-Drafts are working documents and
have no official standards status whatsoever. They may, eventually, have no official standards status whatsoever. They may, eventually,
turn into a standards-track document or they may sink from sight. turn into a standards-track document or they may sink from sight.
Internet-Drafts are submitted to: internet-drafts@ietf.org Internet-Drafts are submitted to: internet-drafts@ietf.org
The format of an Internet-Draft must be the same as for an RFC [2]. The format of an Internet-Draft is mostly the same as for an RFC
Further, an I-D must contain: [RFC7322], Section 4; details can also be found at
https://authors.ietf.org (https://authors.ietf.org). In addition, an
I-D must contain:
- Beginning, standard, boilerplate text which is provided by the * The I-D filename; and
Secretariat on their web site and in the ftp directory;
- The I-D filename; and
- The expiration date for the I-D.
Complete specification of requirements for an Internet-Draft are * The expiration date for the I-D.
found in the file "1id-guidelines.txt" in the Internet-Drafts
directory at an Internet Repository site. The organization of the
Internet-Drafts directory is found in the file "1id-organization" in
the Internet-Drafts directory at an Internet Repository site. This
file also contains the rules for naming Internet-Drafts. (See [1]
for more information about Internet-Drafts.)
7.3. Request For Comments (RFC) * Standard boilerplate which can be found in Section 6 of the Trust
Legal Provisions (https://trustee.ietf.org/documentation/trust-
legal-provisions)
The tooling available to authors automates most the above.
8.3. Request For Comments (RFC)
The work of an IETF working group often results in publication of one The work of an IETF working group often results in publication of one
or more documents, as part of the Request For Comments (RFCs) [1] or more documents, as part of the Request For Comments (RFCs)
series. This series is the archival publication record for the [_2026bis] series. This series is the archival publication record
Internet community. A document can be written by an individual in a for the Internet community. A document can be written by an
working group, by a group as a whole with a designated Editor, or by individual in a working group, by a group as a whole with a
others not involved with the IETF. designated Editor, or by others not involved with the IETF.
NOTE: The RFC series is a publication mechanism only and publication NOTE: The RFC series is a publication mechanism only and publication
does not determine the IETF status of a document. Status is does not determine the IETF status of a document. Status is
determined through separate, explicit status labels assigned by the determined through separate, explicit status labels assigned by the
IESG on behalf of the IETF. In other words, the reader is reminded IESG on behalf of the IETF. In other words, the reader is reminded
that all Internet Standards are published as RFCs, but NOT all RFCs that all Internet Standards are published as RFCs, but NOT all RFCs
specify standards [4]. specify standards [RFC1796].
7.4. Working Group Last-Call 8.4. Working Group Last-Call
When a WG decides that a document is ready for publication it may be When a WG decides that a document is ready for publication it may be
submitted to the IESG for consideration. In most cases the submitted to the IESG for consideration. In most cases the
determination that a WG feels that a document is ready for determination that a WG feels that a document is ready for
publication is done by the WG Chair issuing a working group Last- publication is done by the WG Chair issuing a working group Last-
Call. The decision to issue a working group Last-Call is at the Call. The decision to issue a working group Last-Call is at the
discretion of the WG Chair working with the Area Director. A working discretion of the WG Chair working with the Area Director. A working
group Last-Call serves the same purpose within a working group that group Last-Call serves the same purpose within a working group that
an IESG Last-Call does in the broader IETF community (see [1]). an IESG Last-Call does in the broader IETF community (see
[_2026bis]).
7.5. Submission of documents 8.5. Submission of documents
Once that a WG has determined at least rough consensus exists within Once that a WG has determined at least rough consensus exists within
the WG for the advancement of a document the following must be done: the WG for the advancement of a document the following must be done:
- The version of the relevant document exactly as agreed to by the WG * The version of the relevant document exactly as agreed to by the
MUST be in the Internet-Drafts directory. WG MUST be in the Internet-Drafts directory.
- The relevant document MUST be formatted according to section 7.3. * The relevant document MUST be formatted according to Section 8.3.
- The WG Chair MUST send email to the relevant Area Director. A copy * The WG Chair MUST send email to the relevant Area Director. A
of the request MUST be also sent to the IESG Secretariat. The mail copy of the request MUST be also sent to the IESG Secretariat.
MUST contain the reference to the document's ID filename, and the The mail MUST contain the reference to the document's ID filename,
action requested. The copy of the message to the IESG Secretariat and the action requested. The copy of the message to the IESG
is to ensure that the request gets recorded by the Secretariat so Secretariat is to ensure that the request gets recorded by the
that they can monitor the progress of the document through the Secretariat so that they can monitor the progress of the document
process. through the process.
Unless returned by the IESG to the WG for further development, Unless returned by the IESG to the WG for further development,
progressing of the document is then the responsibility of the IESG. progressing of the document is then the responsibility of the IESG.
After IESG approval, responsibility for final disposition is the After IESG approval, responsibility for final disposition is the
joint responsibility of the RFC Editor, the WG Chair and the Document joint responsibility of the RFC Editor, the WG Chair and the Document
Editor. Editor.
8. Review of documents 9. Review of documents
The IESG reviews all documents submitted for publication as RFCs. The IESG reviews all documents submitted for publication as RFCs.
Usually minimal IESG review is necessary in the case of a submission Usually minimal IESG review is necessary in the case of a submission
from a WG intended as an Informational or Experimental RFC. More from a WG intended as an Informational or Experimental RFC. More
extensive review is undertaken in the case of standards-track extensive review is undertaken in the case of standards-track
documents. documents.
Prior to the IESG beginning their deliberations on standards-track Prior to the IESG beginning their deliberations on standards-track
documents, IETF Secretariat will issue a "Last-Call" to the IETF documents, IETF Secretariat will issue a "Last-Call" to the IETF
mailing list (see [1]). This Last Call will announce the intention of mailing list (see [_2026bis]). This Last Call will announce the
the IESG to consider the document, and it will solicit final comments intention of the IESG to consider the document, and it will solicit
from the IETF within a period of two weeks. It is important to note final comments from the IETF within a period of two weeks. It is
that a Last-Call is intended as a brief, final check with the important to note that a Last-Call is intended as a brief, final
Internet community, to make sure that no important concerns have been check with the Internet community, to make sure that no important
missed or misunderstood. The Last-Call should not serve as a more concerns have been missed or misunderstood. The Last-Call should not
general, in-depth review. serve as a more general, in-depth review.
The IESG review takes into account responses to the Last-Call and The IESG review takes into account responses to the Last-Call and
will lead to one of these possible conclusions: will lead to one of these possible conclusions:
1. The document is accepted as is for the status requested. 1. The document is accepted as is for the status requested. This
This fact will be announced by the IETF Secretariat to the IETF fact will be announced by the IETF Secretariat to the IETF
mailing list and to the RFC Editor. mailing list and to the RFC Editor.
2. The document is accepted as-is but not for the status requested. 2. The document is accepted as-is but not for the status requested.
This fact will be announced by the IETF Secretariat to the IETF This fact will be announced by the IETF Secretariat to the IETF
mailing list and to the RFC Editor (see [1] for more details). mailing list and to the RFC Editor (see [_2026bis] for more
details).
3. Changes regarding content are suggested to the author(s)/WG. 3. Changes regarding content are suggested to the author(s)/WG.
Suggestions from the IESG must be clear and direct, so as to Suggestions from the IESG must be clear and direct, so as to
facilitate working group and author correction of the facilitate working group and author correction of the
specification. If the author(s)/WG can explain to the specification. If the author(s)/WG can explain to the
satisfaction of the IESG why the changes are not necessary, the satisfaction of the IESG why the changes are not necessary, the
document will be accepted for publication as under point 1, above. document will be accepted for publication as under point 1,
If the changes are made the revised document may be resubmitted above. If the changes are made the revised document may be
for IESG review. resubmitted for IESG review.
4. Changes are suggested by the IESG and a change in status is 4. Changes are suggested by the IESG and a change in status is
recommended. recommended. The process described above for 3 and 2 are
The process described above for 3 and 2 are followed in that followed in that order.
order.
5. The document is rejected. 5. The document is rejected. Any document rejection will be
Any document rejection will be accompanied by specific and accompanied by specific and thorough arguments from the IESG.
thorough arguments from the IESG. Although the IETF and working Although the IETF and working group process is structured such
group process is structured such that this alternative is not that this alternative is not likely to arise for documents coming
likely to arise for documents coming from a working group, the from a working group, the IESG has the right and responsibility
IESG has the right and responsibility to reject documents that the to reject documents that the IESG feels are fatally flawed in
IESG feels are fatally flawed in some way. some way.
If any individual or group of individuals feels that the review If any individual or group of individuals feels that the review
treatment has been unfair, there is the opportunity to make a treatment has been unfair, there is the opportunity to make a
procedural complaint. The mechanism for this type of complaints is procedural complaint. The mechanism for this type of complaints is
described in [1]. described in [_2026bis].
9. Security Considerations 10. Security Considerations
Documents describing IETF processes, such as this one, do not have an Documents describing IETF processes, such as this one, do not have an
impact on the security of the network infrastructure or of Internet impact on the security of the network infrastructure or of Internet
applications. applications.
It should be noted that all IETF working groups are required to It should be noted that all IETF working groups are required to
examine and understand the security implications of any technology examine and understand the security implications of any technology
they develop. This analysis must be included in any resulting RFCs they develop. This analysis must be included in any resulting RFCs
in a Security Considerations section. Note that merely noting a in a Security Considerations section. Note that merely noting a
significant security hole is no longer sufficient. IETF developed significant security hole is no longer sufficient. IETF developed
technologies should not add insecurity to the environment in which technologies should not add insecurity to the environment in which
they are run. they are run.
10. Acknowledgments 11. IANA Considerations
This revision of this document relies heavily on the previous version This document has no IANA actions.
(RFC 1603) which was edited by Erik Huizer and Dave Crocker. It has
been reviewed by the Poisson Working Group.
11. References 12. Change Log
[1] Bradner, S., Editor, "The Internet Standards Process -- Revision 12.1. Working group draft
3", BCP 9, RFC 2026, October 1996.
[2] Hovey, R., and S. Bradner, "The Organizations involved in the * Draft 0: Adopted by PROCON WG
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall * Draft 1: Removed sample charter. Fix "conflict of interest" text.
Process: Operation of the Nominating and Recall Committees", BCP Make milestones optional. Clarify IAB liaison to IESG.
10, RFC 2282, February 1998.
[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards", 12.2. Individual draft
RFC 1796, April 1995.
[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC * Draft 0: Translated the nroff source of RFC 2418 into markdown.
2223, October 1997. Changed the intellectual proper notices the current ones.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement * Draft 1: Incorporated RFC 3934. Fixed a few minor typo's and cut/
Level", BCP 14, RFC 2119, March 1997. paste errors. Fixed updates/obsoletes headers and comments.
12. Editor's Address * Draft 2: Incorporate RFC 7475. Fix internal references.
Scott Bradner * Draft 3: Incorporate RFC 8717.
Harvard University
1350 Mass Ave.
Cambridge MA
02138
USA
Phone +1 617 495 3864 * Draft 4: Incoroporate RFC 9141.
EMail: sob@harvard.edu
Appendix: Sample Working Group Charter
Working Group Name: * Draft 5: Incorporate RFC 7776. Text reviewed by Adrian Farrel,
IP Telephony (iptel) one of the RFC authors, since it is not really directly including
text from the RFC.
IETF Area: * Draft 6: Addressed the editorial issues found by the following
Transport Area errata: 6787. Errata 3752. 6130, 7408 were previously fixed.
Chair(s): * Draft 7: Incorporated RFC 8717 (and the bis draft for that) about
Jonathan Rosenberg <jdrosen@bell-labs.com> the name of the IETF Executive Director.
Transport Area Director(s): 13. References
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Responsible Area Director: 13.1. Normative References
Allyn Romanow <allyn@mci.net>
Mailing Lists: [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
General Discussion:iptel@lists.research.bell-labs.com Requirement Levels", BCP 14, RFC 2119,
To Subscribe: iptel-request@lists.research.bell-labs.com DOI 10.17487/RFC2119, March 1997,
Archive: http://www.bell-labs.com/mailing-lists/siptel <https://www.rfc-editor.org/rfc/rfc2119>.
Description of Working Group: [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment
Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March
2016, <https://www.rfc-editor.org/rfc/rfc7776>.
Before Internet telephony can become a widely deployed service, a [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
number of protocols must be deployed. These include signaling and 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
capabilities exchange, but also include a number of "peripheral" May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
protocols for providing related services.
The primary purpose of this working group is to develop two such [RFC9281] Salz, R., "Entities Involved in the IETF Standards
supportive protocols and a frameword document. They are: Process", BCP 11, RFC 9281, DOI 10.17487/RFC9281, June
2022, <https://www.rfc-editor.org/rfc/rfc9281>.
1. Call Processing Syntax. When a call is setup between two 13.2. Informative References
endpoints, the signaling will generally pass through several servers
(such as an H.323 gatekeeper) which are responsible for forwarding,
redirecting, or proxying the signaling messages. For example, a user
may make a call to j.doe@bigcompany.com. The signaling message to
initiate the call will arrive at some server at bigcompany. This
server can inform the caller that the callee is busy, forward the
call initiation request to another server closer to the user, or drop
the call completely (among other possibilities). It is very desirable
to allow the callee to provide input to this process, guiding the
server in its decision on how to act. This can enable a wide variety
of advanced personal mobility and call agent services.
Such preferences can be expressed in a call processing syntax, which [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
can be authored by the user (or generated automatically by some Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995,
tool), and then uploaded to the server. The group will develop this <https://www.rfc-editor.org/rfc/rfc1796>.
syntax, and specify means of securely transporting and extending it.
The result will be a single standards track RFC.
2. In addition, the group will write a service model document, which [RFC2418] Bradner, S., "IETF Working Group Guidelines and
describes the services that are enabled by the call processing Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
syntax, and discusses how the syntax can be used. This document will September 1998, <https://www.rfc-editor.org/rfc/rfc2418>.
result in a single RFC.
3. Gateway Attribute Distribution Protocol. When making a call [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
between an IP host and a PSTN user, a telephony gateway must be used. Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683,
The selection of such gateways can be based on many criteria, March 2004, <https://www.rfc-editor.org/rfc/rfc3683>.
including client expressed preferences, service provider preferences,
and availability of gateways, in addition to destination telephone
number. Since gateways outside of the hosts' administrative domain
might be used, a protocol is required to allow gateways in remote
domains to distribute their attributes (such as PSTN connectivity,
supported codecs, etc.) to entities in other domains which must make
a selection of a gateway. The protocol must allow for scalable,
bandwidth efficient, and very secure transmission of these
attributes. The group will investigate and design a protocol for this
purpose, generate an Internet Draft, and advance it to RFC as
appropriate.
Goals and Milestones: [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
DOI 10.17487/RFC7322, September 2014,
<https://www.rfc-editor.org/rfc/rfc7322>.
May 98 Issue first Internet-Draft on service framework [RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
Jul 98 Submit framework ID to IESG for publication as an RFC. Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
Aug 98 Issue first Internet-Draft on Call Processing Syntax Confirmation, and Recall Process: Operation of the IETF
Oct 98 Submit Call processing syntax to IESG for consideration Nominating and Recall Committees", BCP 10, RFC 8713,
as a Proposed Standard. DOI 10.17487/RFC8713, February 2020,
Dec 98 Achieve consensus on basics of gateway attribute <https://www.rfc-editor.org/rfc/rfc8713>.
distribution protocol
Jan 99 Submit Gateway Attribute Distribution protocol to IESG
for consideration as a RFC (info, exp, stds track TB
Full Copyright Statement [_2026bis] Salz, R. and S. O. Bradner, "The Internet Standards
Process", Work in Progress, Internet-Draft, draft-ietf-
procon-2026bis-00, 30 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-procon-
2026bis-00>.
Copyright (C) The Internet Society (1998). All Rights Reserved. Acknowledgments
This document and translations of it may be copied and furnished to We gratefully acknowledge those who have contributed to the
others, and derivative works that comment on or otherwise explain it development of IETF RFC's and the processes that create both the
or assist in its implementation may be prepared, copied, published content and documents. In particular, we thank the authors of all
and distributed, in whole or in part, without restriction of any the documents that updated [RFC2418].
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be We also thank Sandy Ginoza of the Secretariat for sending all the
revoked by the Internet Society or its successors or assigns. sources of [RFC2418] and the subsequent documents, and John Klensin
for his support and cooperation during the process of creating this
document.
This document and the information contained herein is provided on an Authors' Addresses
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Rich Salz
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Akamai Technologies
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF Email: rsalz@akamai.com
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
David Schinazi
Google LLC
Email: dschinazi.ietf@gmail.com
Scott Bradner
SOBCO
Email: sob@sobco.com
 End of changes. 196 change blocks. 
573 lines changed or deleted 619 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/