Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking
Obsoletes: 2418, 7221 (if approved) R. Droms, Ed.
Updates: 2026 (if approved) Cisco Systems
Intended status: Best Current Practice March 9, 2015
Expires: September 10, 2015

IETF Working Group Guidelines and Procedures


IETF activities are primarily organized into open-participation working groups (WGs). This document describes the formation, requirements, structure, and operation of IETF working groups. This includes the formal relationships and duties of participants.

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

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 September 10, 2015.

Copyright Notice

Copyright (c) 2015 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 ( 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The [IETF] is an open community of network designers, operators, vendors, users, and researchers concerned with the development and operation of Internet technical specifications. Activities of the IETF are primarily performed by committees known as Working Groups [WG]. For administrative purposes, they are organized into topical [Areas]. Working groups are formally chartered, typically with a narrow focus and lifetime bounded by the completion of a specific set of tasks.

This document describes the formation, requirements, structure, and operation of IETF working groups. This includes the formal relationships and duties of participants.

At base, working groups are driven by:

That is, a collection of participants, who fill various roles, work toward some common goal(s), according to IETF requirements. This document is principally organized according to these distinctions.

1.1. Background

This version is organized as an aid to (new) working group participants both as an introduction and as a later reference.

Specifically this version of the document:

A useful introduction to the IETF is The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force [Tao]. Familiarity with The Internet Standards Process [RFC2026] is essential for a complete understanding of the philosophy, procedures and guidelines described in this document.

1.2. Terminology and References

When used in this document the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are normative and are to be interpreted as described in [RFC2119].

Summary text about other documents is solely advisory. Unless explicitly stated otherwise, it MUST NOT be taken as pre-empting the content of those documents.

Throughout the document, there are portions prefaced with a (Task) label. These call out specific actions that are required, suggested, or permitted. Besides being meant to draw the eye to action items that are distinct from surrounding discussion text, these provide an approximate list of tasks that might be assigned to various roles in the working group, as discussed in Section 6.


This list is an invitation for information, pointers, corrections, and additional/different text. In some cases, resolution will require discussion and some version of IETF consensus.

What are the formal WG roles/titles that are a) documented, b) can be written into a charter, and c) can be assigned via the Datatracker? E.g., Consultant vs. Tech Adviser. What are the formal permissions for "Delegated authority"? What are options and what are choices within options?
Doc Publication:
In terms of process, what is formally required vs. typical vs. wg choice. Eg, a) required - wg last call? -- maybe not required, but advisable to avoid an appeal; b) Formal: publication as wg item, when pushing doc out of wg to iesg/rfc editor.
WG Ops vs. Tasks:
Macro vs micro -- Overall wg management, eg, meetings and task sequencing; vs. managing a task, eg, doc revisions, issue tracking, writer/wg relationship.
Besides RFC 2026, what other IETF docs are "required" for the reader to have familiarity with?
Charter negotiation:
WHO NEGOTIATES A CHARTER??? Distinguish required vs. flexible. Emphasize open and accountable.
What other RFCs, IESG Statements, etc. need to be cited?
Mailing List Hosting:
(Secretariat queried) Are IETF working group mailing lists now required to be hosted at the IETF?
make sure example charter in Appendix A includes milestones
Email -- " the Area Director, with the approval of the IESG, MAY request that the mailing list maintainer block the ability of the offending individual to post to the mailing list." Is it the AD that does this? Who really does?
Docs on Agenda:
"Any document which does not meet this publication deadline can only be discussed in a working group session with the specific approval of the working group chair(s)." Current operation is that /all/ items on an agenda are explicitly approved by the chair/wg??? -- distinguish "IETF" deadline from "WG-specific" requirement(s)."
What should be moved to the Wiki or added to it?
Review references for normative/non-normative placement listing in doc.
Resolve various IETF website pages concerning submission and archive of notes, etc?
Milestone Revision:
Revised milestones MUST be approved by the cognizant Area Director. Is any other review or approval needed, such as from the IESG?

2. Basic Structure and Requirements

The IETF permits wide variation in the conduct of working group affairs. Still, there is a core of required organization and required operation. This section describes that core.

2.1. Working Group Charter

A working group is based on a formal a charter, which is a contract between a working group and the IETF to perform a set of tasks. A charter: Section 7.2.

Details concerning charters are provided in

2.2. Deliverables

A working group's charter specifies deliverables to be achieved. (Section 7.2) These are usually documents to be published in the Request for Comments series [RFC-Editor]. The means of achieving those deliverables is only lightly constrained: whatever permits a working group to conduct a fair, open and accountable process, while achieving working group rough consensus, is permitted. The challenge with this flexibility is formulating the details of internal working group structure and process in a manner that ensures timely achievement.

In other words, the group needs to efficiently balance fair and open discussion, proper attention to legitimate concerns, and making forward progress.

2.3. Mailing List

A process that is truly open and inclusive makes participation as easy as possible, for the widest range of participants as possible. For the IETF, that means that the primary venue for working group activities MUST be the mailing list associated with the group. (Section 7.2) Further, the mailing list MUST be the only venue for formally assessing working group rough consensus.

It is important to ensure that the discussions on this list are relevant and that they converge to consensus agreements.
It can help to summarize a discussion periodically.
It also can help later review to ensure that outcomes are well and explicitly 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).


Mailing lists related to IETF activities are usually hosted at the IETF, but generally MAY be hosted elsewhere.

A message archive MUST be maintained in a public place which can be accessed via FTP or via the web.

As a service to the community, the IETF Secretariat operates a mailing list archive for working group mailing lists. In order to take advantage of this service, working group mailing lists MUST include the address:{ACRONYM}/current/maillist.html

Multiple versions of list archives are available, as indicated in the "Archives" section of [MailList]. One form is located at:


IETF Working Groups are administratively aggregated into "areas". Each working group has a designated ("cognizant") Area Director [AD] ([AD-Desc],[Areas]), to formally select chairs for the working group and to provide oversight.

2.5. Chair(s)

Working Group Chairs are formally responsible for ensuring that the working group makes forward progress through a fair and open process. They have wide discretion in the conduct of WG business. However within the bounds of IETF formal requirement, Chairs are always accountable to the rough consensus [Consensus] of the working group participants, as well as to the Area Director who appointed them. Chairs ensure that a number of procedural, administrative and project management tasks are performed, either directly or by others assigned to the tasks.

Chairs have the authority and the responsibility to make decisions, on behalf of the working group, regarding all matters of internal working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention.

The choices for assignment of tasks are highly dependent upon the nature of the working group topic, the nature of the work to be done, and the nature of working group participation. When a topic is well-understood, the deliverables straightforward and the participants generally knowledgeable and compatible, a very streamlined working group organization can be quite reasonable. As topic and/or participation get more challenging, working group operation typically needs to be more actively and formally managed, typically requiring administrative tasks to be spread among other participants and processes for discussion and decision-making more structured.

2.6. Document Writer

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 group designates one or more people to serve as the Writer for a particular document. The Document Writer is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group.

As a general practice, the Working Group Chair and Document Writer positions are filled by different individuals to help ensure a clear distinction between process management and content generation. This helps the resulting documents to accurately reflect the consensus of the working group. However this separation is not a firm requirement. Especially in a small, narrow, simple effort among a cohesive group, it might be convenient and efficient for the Chair and Writer roles to be combined.

The Document Writer is variously called an "author" or an "editor". The IETF does not have consistent rules for distinguishing use of these terms. However, see Section 3 of [RFC7221] for a suggested distinction between primary responsibility for creating concepts and content, versus responsibility for recording content developed by the working group itself.

2.7. Participants

The foundation of a working group is its participants. Within the scope of the charter, working group participants represent the entire Internet, indicating what output is needed from the working group effort -- including who will use it and why -- and providing guidance, ideas, text, discussion, and assessment. For all substantive choices, the 'rough consensus' of the participants determines the real work of the group.

WG participants MUST conform to the requirements for disclosure of conflicts of interest in [RFC2028].

2.8. Rough Consensus Decision Making

The IETF does not have "members" and it's open processes can not make decisions by "voting". Rather, a community sense of strongly-dominant agreement, in the absence of compelling objections, is used to make decisions. This is called Rough Consensus [RFC7282]. Within working group processes, this is the required means for making working group decisions, but more importantly it is a model for considering issues.

In the abstract, nearly all working group activities and decisions are subject to Rough Consensus. In practice, working group chairs often make decisions based on the assumption of working group support. This practice is essential for working group efficiency, but its risk is that the chair's choices will not actually be in sync with the working group's desires. Consequently, all participants carry the responsibility of voicing concerns they consider significant, even when no other participant has spoken up.
A major challenge in considering Rough Consensus appears to be distinguishing between active and passive support. Active support is indicated by participants that are actively engaged in discussing the topic, whereas passive has, at most, pro forma expressions of support, without any obvious indication that the topic is both understand and important to the participant. The dangers of passive support are that it could mean the topic is not adequately understood and/or that the topic will not obtain community followup, such as deployment and use.
The other major challenge, as discussed in [RFC7282], is that "minority" concerns are not adequately addressed. In particular in the interest of moving the working group effort along, it is easy to marginalize such concerns because they are expressed by few participants. What this risks is failure to attend to problems that are serious and will affect utility of the work later. There is, of course, a competing pressure that 'minority' voices could stall the working group. So the core working group challenge with a minority concern is to adequately consider its nature and adequately consider its effect, while still making forward progress.

3. Documents

3.1. Home Page{ACRONYM}/documents/

Each working group has an associated web page, listing working group documents and pointing to a variety of related other pages. The working group home page is located at:

3.2. Wiki{ACRONYM}/trac/wiki

Working groups can have access to an editable wiki, if requested by a Chair, for use as the working group sees fit. It is located at:

3.3. Issue-tracking Tickets

As topics, issues and suggestions increase for a working group, it can be helpful to document them in an issue tracking system.{ACRONYM}/trac/report

One can be provided through the working group wiki, if requested by a Chair, at the tab for "View Tickets":

3.4. Meeting Materials

Any organized working group session (meeting) will have planning and reporting material, including:[MeetMaterials], [MeetMaterialTool].

The planning and presentation material needs to be made available in advance of the session.
They and the reporting materials also need to be preserved for later reference.

Details about IETF Meeting Materials are provided in

The IETF web site has related information that appears to be out of date, such as [AgendaNotes].

3.5. Internet-Drafts (I-D)

Working group efforts are typically driven by specific documents. Some are used to fuel working group discussion while others are the deliverable product under development. Documents are processed as Internet Drafts [I-D], which are strictly working documents and have no official standards status whatsoever. They might, eventually, turn into a standards-track document or they might sink from sight.

Formal adoption of Internet Drafts in a working group is discussed in [RFC7221]. Also, there are naming conventions, to identify Internet Drafts that have been adopted by a working group, as described in Section 7 of [I-D-Guidelines].

3.6. Request For Comments (RFC)

The work of an IETF working group typically targets publication of one or more documents, as part of the Request For Comments (RFC) series. ([RFC-IETF], [RFC-Editor], [RFC2026]) This series is the archival publication record for the Internet community. There are multiple, independent streams that produce documents published as RFCs; the IETF stream is one of these. A document can be written by an individual in a working group, by a group as a whole with a designated Writer, or by others not involved with the IETF. The RFC Editor provides guidance for writing an RFC. [RFC7322]

NOTE: The RFC series is a publication mechanism only and publication does not determine the IETF status of a document. RFCs are processed through a number of independent 'streams', of which those produced with IETF approval represent one. The IETF status is determined through separate, explicit status labels assigned by the 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 specify standards. [RFC1796]

4. Working Group Internal Operation

4.1. Prime Directives

The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. Within those constraints, working groups are nearly autonomous and each determines most of the details of its own operation with respect to organization, planning, session participation, discussion style, means of reaching closure, etc.

A number of procedural questions and issues will arise over time. The Working Group Chair(s) have ultimate responsibility for management of the group process, keeping in mind that the overall purpose of the group is to make progress towards reaching rough consensus in realizing the working group's goals and objectives.

There are few hard and fast rules on organizing or conducting working group activities, but a set of guidelines and practices has evolved over time that have proven successful. Some basic choices are listed in (Section 6). These are discussed at length in the associated wiki. (Appendix C)

Actual choices for the details of working group operation are determined by the working group participants and the Chair(s).

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 Writer to one or two participants. Sometimes, they also are part of the design team, described below. (Section 6)

Of course, each WG will have participants who might 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 and the necessary representation of Internet community requirements.

4.2. General Organizing

Working groups sometimes develop and operate organically, needing very little assertive management by the Chairs. Such groups are nearly self-regulating and that is entirely acceptable, but it also is rare. When a working group has to do simple tasks, and the working group is cohesive and knowledgeable, there is little need for much formality in working group management. Most working groups are not so fortunate. For them, active management might be required, to determine such things as the sequence of work, the design teams for doing core work, issue-tracking, the approach for resolving issues, and even discussion facilitation.

4.2.1. Characterizing the Effort

It can help to evaluate the work to be done and the participation in the working group that will do it:

4.2.2. Plan of Work

Working groups typically produce more than one document. While there might appear to be a natural sequence for developing them, consider that some foundational documents that logically need to be done first might also need to be revised later, as the working group gains more experience with its topic(s).

Given a sequence of documents, what are the subordinate steps that will achieve necessary milestones? It can help to chart this explicitly in the working group Wiki. [Wiki]

4.2.3. Tasks vs. Roles

A working group requires significant administrative and management work. What is flexible is who performs the work. The choices for assigning one or more tasks to a participant filling a particular role will depend upon the assessment of the Chair(s). For example, as the scale or complexity or contentiousness of a working group increases, so does its risk of failure and its attendant need for more active and more formal management.

This typically means stricter adherence to formal rules of working group process and assignment of various tasks to a wider set of participants in specific roles, so that each task receiver proper focus. Roles that are required or, at least, useful are discussed later, in (Section 6).

4.2.4. Venues

Although the working group mailing list is intended to be the primary venue for discussion and MUST be the ultimate venue for assessing working group rough consensus, scheduled meetings can also be important. (Some successful efforts have taken place only on mailing lists, with no interactive meetings, but these are rare.)

Meetings can be face-to-face, such as during the thrice-annual IETF Plenary Meeting, or "virtual" via teleconference or chat session. Face-to-face meetings can (and often do) include provisions for virtual participation to accommodate participants who cannot attend in person. See: Section 4.6, Section 4.7, Section 4.6.4.

4.3. Discussion and Progress

The challenge to managing working group discussion is to balance the need for open and fair consideration of the issues against the need to make forward progress. The working group, as a whole, has the final responsibility for striking this balance.

The Chair has the responsibility for overseeing the process but MAY delegate direct process management to a formally-designated Facilitator.

It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group's understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if:

Main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion.

It is also good practice to:

Note important decisions/consensus reached by email in the notes of the next 'live' session, and to summarize briefly the decision-making history in the final documents the WG produces.

To facilitate making forward progress, a working group MAY decide to reject or defer the input from a participant, based upon the following criteria:
The input pertains to a topic that already has been resolved and is redundant with information previously available;
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 decision;
The input pertains to a topic that the working group has not yet opened for discussion; or Scope The input is outside of the scope of the working group charter.

4.4. IETF Open Decision-Making

The IETF values and demands open, inclusive decision-making by working groups. A process that is truly open and inclusive makes participation as easy as possible, for the widest range of participants as possible.

Working groups make decisions through a "rough consensus" process [Consensus], which entails considerably more than merely determining that a majority are for or against a particular choice. IETF rough consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group needs to prevail, absent compelling arguments against. In particular note the role of "minority" views, as discussed in [RFC7282].

It can be especially challenging to gauge the level of consensus on a mailing list. There are two different cases where a working group might 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 not, by itself, a good indicator of consensus since one or two individuals might be generating much of the traffic.

Enough time MUST be given to the verification process for the mailing list readers to understand and consider any objections that might be raised on the list. The normal two week last-call period SHOULD be sufficient for this.

4.5. Mailing List Primacy

Discussions relating to working group topics MAY happen anywhere, amongst any group of people, on a spontaneous or continuing basis and as a closed or open set. Closed groups that persist with a continuing role in providing substantive input to the working group's content are called 'design teams'. They can be self-forming or created by the Chair(s).

The working group, itself, can provide a variety of open discussion venues, over the life of the working group, as discussed below. However discussions are conducted, "decisions" made at venues other than the working group mailing list MUST be treated as preliminary, and MUST be explicitly documented and confirmed through the mailing list.

An example method is to post a note summarizing:

This provides working group participants with enough foundational material to understand the proposal and comment on it or even support it. It also creates a record on the official email archive.

If discussion is held entirely over the mailing list, determination of the level of consensus might be harder to do, since most people subscribed to mailing lists do not actively participate in discussions. It is 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 group chair to state what they believe to be the consensus view and at the same time, request comments from the list about the stated conclusion.

4.6. Discussion Venues

Each working group will determine the balance of email versus interactive (face-to-face, online, ...) sessions that is appropriate for achieving its milestones. Electronic mail permits the widest participation; interactive, real-time meetings often permit better focus and therefore can be more efficient for reaching a consensus among a core of the working group participants. In determining the balance, the WG MUST ensure that its process does not serve to exclude contribution by email-only participants.

Remember that consensus reached during an interactive MUST be reviewed on the mailing list.

4.6.1. Tradeoffs

Each working group will determine the balance of email versus interactive (face-to-face, online, ...) sessions that is appropriate for achieving its milestones. The choices are affected by various factors, including the working group's milestone schedule -- that is, degree of urgency -- complexity of the work, number of active discussants, and the schedule and support of those discussants.

However there tends to be a significant tradeoff between doing work at interactive sessions, versus working group inclusiveness.

Interactive sessions demand that a participant's schedule permit availability during the sessions. Even when held online, this can be a significant burden for some participants. Even if their formal schedule is sufficiently flexible, the fact of different participant timezones tends to work to the disadvantage of some participants.

If the meetings are face-to-face, the schedule and monetary demands are dramatically higher and, obviously, further restrict participation.

A mailing list venue permits the widest and most-convenient participation, by allowing for time-shifted debate among participants in multiple time zones. Its asynchrony also permits the most thoughtful presentation of views and the most thoughtful consideration of them.

Interactive, real-time meetings often provide richer and higher speed communication with lower latency and therefore permit better focus. They therefore can be more efficient for reaching a consensus among a core of the working group participants, especially for narrow and contested choices.

Any tools that permit real-time, or time-shifted, interaction and information exchange could be used, without affecting the basic principle that decisions are exposed and confirmed on the mailing list -- Facebook, Twitter, github, issue tracker, etc. Note that these do not provide a formal, IETF archive of the activity, although their record can be useful to cite.

A basic principle is that although face-to-face discussion, either during a plenary week or at an interim meeting, might sometimes be considered essential to make rapid progress or to resolve tricky issues, this MUST NOT be discriminatory against those unable to attend. As far as technically and financially possible, facilities for passive and active remote participation SHOULD be provided.

Similarly, "virtual" interim meetings in which all participants are remote MUST NOT be discriminatory against those unable to attend.

4.6.2. Mailing List Discussion Management

It can be quite useful to conduct email exchanges in the same manner as an interactive session, with published schedule and agenda, as well as on-going summarization and consensus polling, even though message-posting and responding continues to be asynchronous amongst participants.

WG chairs should guide WG email debate when necessary, for example by encouraging participants to stay on topic, remain polite, avoid repetition, etc. It is helpful to encourage distinct threads with meaningful subject headers for distinct topics.

As with face-to-face sessions occasionally a participant might engage in behavior on a mailing list which disrupts the WG's progress.

In these cases the Chair SHOULD attempt to discourage the behavior by communication directly with the offending individual rather than on the open mailing list. If the behavior persists then the Chair MUST involve the Area Director in the issue.
As a last resort and after explicit warnings, the Area Director, with the approval of the IESG, MAY request that the mailing list maintainer block the ability of the offending individual to post to the mailing list. (If the mailing list software permits this type of operation.) Even if this is done, the individual MUST NOT be prevented from receiving messages posted to the list.

Other methods of mailing list control MAY be considered but MUST be approved by the AD(s) and the IESG.

4.6.3. IETF Plenary Meetings

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 made by the IETF Secretariat to the WG-chairs list. Session time is a scarce resource at IETF meetings, so placing requests early will facilitate schedule coordination for WGs requiring the same set of experts.

Some Area Directors MAY want to coordinate WG sessions in their area and request that time slots be coordinated through them. If this is the case it will be noted in the IETF meeting announcement.
Requirements and procedures for obtaining a session slot at an IETF Meeting are specified in [MeetRequest].

NOTE: While open discussion and contribution is essential to working group success, the Chair is responsible for ensuring forward progress. When acceptable to the WG, the Chair MAY call for restricted participation (but not restricted attendance!) at IETF working group sessions for the purpose of achieving progress.

The Working Group Chair has the authority to refuse to grant the floor to any individual who is unprepared, is covering inappropriate material, or who in the opinion of the Chair is disrupting the WG process.

The Chair SHOULD consult with the Area Director(s) if the individual persists in disruptive behavior.

4.6.4. Interim Meetings

In addition to mailing list discussion and meeting at the thrice-yearly IETF Meetings, a working group might decide that it should hold an additional, real-time "interim" meeting. This might be through a real-time chat session, group telephone call, online teleconference, or physical, face-to-face meeting.

Guidance for the conduct of such sessions is provided by [Interim], with useful tutorial material at [Interim-Train]. Also see: Section 4.7.

4.7. Session Planning

Administrative and process details for the conduct of structured meetings are referenced at [IETF-Meetings] and in [Interim]

Sessions MUST be planned, organized and announced well in advance.

[MeetMaterials], [MeetMaterialTool].

For coordinated, structured WG interactions, a draft agenda SHOULD be published well in advance of the actual session.

Details about Meeting Materials are provided in

4.8. Meeting Drafts and Documents

The requirements here apply to all IETF working group meetings, independent of venue or mode. That is, all official sessions during an IETF Week and all interims.

All relevant documents to be discussed at a session SHOULD be published and available as Internet-Drafts at least two weeks before a session starts, so that working group participants have adequate time to review all documents.

4.9. Meeting Record Keeping

The requirements here apply to all IETF working group meetings, independent of venue or mode. That is, all official sessions during an IETF Week and all interims.

The task(s) of creating records about meeting activity are discussed in [AgendaNotes], above.

An attendance list MUST be circulated
Notes of a session MUST be taken; they SHOULD include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees
Immediately after a session, the WG Chair SHOULD provide the Area Director with a very short report (approximately one paragraph, via email) on the session.

5. Document Development & Lifecycle

Working groups produce documents and documents need Writers.

The Chair MUST make sure that Document Writers incorporate changes as agreed to by the WG.

It is quite easy for active and productive writers to move into a dominant position, either making changes faster than the working group can absorb, or becoming adversarial with working group preferences. An especially conducive environment for this problem combines original (pre-working group) authors with a more passive working group. However a working group that does not fully and actively support a specification, the greater the risk that it will not achieve deployment and use.

5.1. Basic Sequence

Working group development of a document proceeds through these steps:

  1. An individual or a group has something for the WG to discuss and publishes a document on the topic as an individual I-D
  2. WG adopts the document as a WG work item, per section 2 of [RFC7221]
  3. WG develops the document, per [RFC7221]
  4. When the WG is done with development, the chairs organize a WG last call to determine consensus for sending the I-D to the IESG for review and publication
  5. Chairs assign a document shepherd who prepares the cover sheet and assumes responsibility for managing the review and publication process
  6. The Working Group, through the chairs or the shepherd, make a recommendation to the to the Area Director that a standards action be approved regarding the document [RFC 2026]
  7. Area Director reviews the document to determine if the standards action should proceed; this review may include an external review, per [RFC2026]
  8. Area Director formally requests an IETF Last Call to determine IETF consensus about whether the I-D is ready for publication, per [RFC2026]
  9. Once the IETF Last Call is complete, the AD, the document shepherd, the editors and the WG agree on any changes to the I-D based on the Last Call comments
  10. The AD schedules the I-D for discussion during an IESG telechat
  11. Prior to the telechat, IESG members post a ballot position on the I-D
  12. After the telechat, the I-D may require additional revision; the IESG, the document shepherd, the editors and the WG agree on any changes to the I-D based on the IESG ballot positions and telechat discussion
  13. Once the I-D meets the IESG ballot requirements for publication, the IETF is notified of any associated standards action and the document is forwarded to the RFC Editor

5.2. Early Document Review

It is easier to make substantial changes to a specification during its early stages than it is later on. Periodically, the IETF's various late-stage reviews uncover basic concerns with assumptions or approaches in a design. When a working group is pursuing a solution that has unusual design choices or unusual operational characteristics, or has any other feature that might impede its success, or when the working group participants have less experience in producing specifications for Internet-scale use, it is advisable to recruit review and advice from a broad base of experts.

5.3. Document Coordination Between Working Groups

A document is adopted by one working group as a deliverable; they are therefore responsible for its development, review and publication. (Section 3.5) When initiated outside a working group environment, the writer(s) usually have a specific -- possibly new -- working group in mind as the development home. However some documents address problems or contain technologies that span multiple Areas or working groups. In such cases, the document is assigned to one of these, with other interested groups participating in the development process. This joint participation can take many forms. One example is a joint Working Group Last Call conducted by the host group but announced on the mailing lists for the other interested groups.

As an example, documents that extend DHCP to carry configuration information for other protocols often span multiple working groups. Some of these documents define a simple DHCP option that follows one of the option formats in section 5 of [RFC7227]. Such options can be developed in the working group responsible for the protocol that will use the option, without significant participation of the dhc working group. A joint last call between the two groups might be all that is required. However some documents will define options that have a significantly new option format, or define a new DHCP message or otherwise make a fundamental change to the semantics of DHCP message exchanges. These options or new messages will be developed in the dhc working group, with input from other interested groups, to ensure that there are no conflicts or other issues with the documents that would cause problems with the DHCP standards.

5.4. Working Group Last-Call

When a WG decides that a document is ready for publication it is submitted to the IESG for consideration. In most cases the determination that a WG feels that a document is ready for 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 discretion of the WG Chair working with the Area Director. A working group Last-Call serves the same purpose within a working group that an IESG Last-Call does in the broader IETF community. ([RFC2026])

5.5. Final External Review of Documents

The IESG reviews all documents submitted for publication as RFCs. Usually minimal IESG review is necessary in the case of a submission from a WG intended as an Informational or Experimental RFC. More extensive review is undertaken in the case of standards-track documents.

Prior to the IESG beginning their deliberations on standards-track documents, IETF Secretariat will issue a "Last-Call" to the IETF mailing list. ([RFC2026]) This Last Call will announce the intention of the IESG to consider the document, and it will solicit final comments from the IETF within a period of two weeks. It is important to note that a Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review.

The IESG review takes into account responses to the Last-Call and will lead to one of these possible conclusions:

  1. The document is accepted as is for the status requested. This fact will be announced by the IETF Secretariat to the IETF mailing list and to the RFC Editor.
  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 mailing list and to the RFC Editor. (See [RFC2026] for more details.)
  3. Changes regarding content are suggested to the Writer(s)/WG. Suggestions from the IESG need to be clear and direct, so as to facilitate working group and Writer correction of the specification. If the Writer(s)/WG can explain to the satisfaction of the IESG why the changes are not necessary, the document will be accepted for publication as under point 1, above. If the changes are made the revised document MAY be resubmitted for IESG review.
  4. Changes are suggested by the IESG and a change in status is recommended. The process described above for 3 and 2 are followed in that order.
  5. The document is rejected. Any document rejection will be accompanied by specific and thorough arguments from the IESG. Although the IETF and working group process is structured such that this alternative is not likely to arise for documents coming from a working group, the IESG has the right and responsibility to reject documents that the IESG feels are fatally flawed in some way.

If any individual or group of individuals feels that the review treatment has been unfair, there is the opportunity to make a procedural complaint. The mechanism for this type of complaints is described in [RFC2026].

6. Staff Roles

From initial chartering, through document development and publication, ending with working group termination, there are tasks that are formally required to be done, while others are merely -- though often very -- helpful to do. This document discusses the formal tasks and many of the other, useful tasks.

Working groups require considerable care and feeding. In addition to general participation, successful working groups benefit from the efforts of participants filling specific functional roles.

Beyond a limited set of formal tasks, there are no rules about who MAY be assigned tasks internal to the working group. This section discusses possible mappings between working group tasks and working group participants who might be assigned roles for performing those tasks. However it is important to remember that such mappings are strictly at the discretion of the chairs, assuming working group agreement.

[RFC2028] describes the roles of a number of individuals related to external aspects of working groups, as well including the working group chair and the document Writer. These descriptions are expanded later in this section.

6.1. Development

Document Writer:
This role is discussed in Section 2.6.
Design Team:
It is often useful, and perhaps inevitable, for a sub-group of a 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 to remain small and agile, it is acceptable to have closed membership and private meetings. Operationally, a design team typically is advisory to the Document Writer(s), specifically, or the working group discussion, generally. Design teams can range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair appoints to attack a controversial problem. The output of a design team always MUST be subject to approval, rejection or modification by the WG as a whole.
Discuss issues. Suggest ideas and text. Review documents. Actively pursue resolution of topics.

6.2. Advice

Adviser (WG Consultant):
At the discretion of the Area Director or Chair, an Adviser MAY be assigned to a working group. Consultants have specific technical background appropriate to the WG and experience in Internet architecture and IETF process. An adviser's role is strictly advisory rather than authoritative. However of course their concerns are likely to gain the attention of reviewers, the Area Director and the IESG.

6.3. Process

Area Director:
This role is discussed in Section 2.4.
Working Group Chair:
This role is discussed in Section 2.5.
WG Facilitator:
When meetings tend to become distracted or divisive, it often is helpful to assign the task of "process management" to one participant. [Facilitate] Their job is to oversee the nature, rather than the content, of participant interactions. That is, they attend to the style of the discussion and to the schedule of the agenda, rather than making direct technical contributions themselves.
WG Secretary:
Taking notes, producing discussion summaries, and maintaining a list of working group action items are tasks often is performed by one or more designated participants.
A Scribe is tasked with note-taking during a meeting. This might be for real-time use during the session, such as providing quick summaries of on-going discussion via an instant-messaging channel, to assist remote participants. Or it might be basic meeting notes; these are typically summarizations of discussions, rather than detailed 'minutes'. [I-D-Jscribe]

7. WG External Administration

7.1. Working group Formation

IETF working groups (WGs) are the primary means of developing IETF specifications and guidelines, many of which are intended to be standards or recommendations. Working groups are typically created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.). Working groups are generally expected to be short-lived in nature.

A working group is typically created by a community initiative, but can also be established at the initiative of an Area Director. Anyone interested in creating an IETF working group MUST obtain the advice and consent of IETF Area Director(s) and MUST proceed through the formal steps detailed in this section.

7.1.1. Criteria for formation

When determining whether it is appropriate to create a working group, the Area Director(s) and the IESG will consider several issues:

Are the issues that the working group plans to address clear and relevant to the Internet community?
Are the goals specific and reasonably achievable, and achievable within a reasonable time frame?
What are the risks and urgency of the work, to determine the level of effort required?
WG Overlap:
Do the working group's activities overlap with those of another working group? If so, it can still be appropriate to create the working group, but this question needs to be considered carefully by the Area Directors as subdividing efforts often dilutes the available technical expertise.
Is there sufficient interest within the IETF in the working group's topic with enough people willing to expend the effort to produce the desired result (e.g., a protocol specification)? Working groups require considerable effort, including management of the working group process, editing of working group documents, and contributing to the document text. IETF experience suggests that these roles typically cannot all be handled by one person; a minimum of four or five active participants in the management positions are typically required in addition to a minimum of one or two dozen people that will attend the working group meetings and contribute on the mailing list. NOTE: The interest needs to be broad enough that a working group would not be seen as merely the activity of a single vendor.
Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group?
Does a base of interested consumers (end-users) appear to exist for the planned work? Consumer interest can be measured by participation of end-users within the IETF process, as well as by less direct means.
IETF Relevance:
Does the IETF have a reasonable role to play in the determination of the technology? There are many Internet-related technologies that might be interesting to IETF participants but in some cases the IETF might not be in a position to effect the course of the technology in the "real world". This can happen, for example, if the technology is being developed by another standards body or an industry consortium.
Are all known intellectual property rights relevant to the proposed working group's efforts issues understood?
Real IETF Work:
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 participants might be limited?
Existing Work:
Is there a good understanding of any existing work that is relevant to the topics that the proposed working group is to pursue? This includes work within the IETF and elsewhere.
SDO Overlap:
Do the working group's goals overlap with known work in another standards body, and if so is adequate liaison in place?

Considering the above criteria, the Area Director(s) will use their best judgment to decide whether to pursue formation of the group through the chartering process.

7.1.2. Birds of a Feather (BOF)

Often it is not clear whether an issue merits the formation of a working group. To facilitate exploration of the issues the IETF offers the possibility of a Birds of a Feather (BOF) session ([RFC5434]) as well as the early formation of an email list for preliminary discussion. In addition, a BOF can serve as a forum for a single presentation or discussion, without any intent to form a working group.

A BOF is a session at an IETF meeting which permits "market research" and technical "brainstorming". Any individual MAY request permission to hold a BOF on a subject. The request MUST be filed with a relevant Area Director, and their approval MUST be obtained before a BOF can be scheduled. The person who requests the BOF MAY be asked to serve as Chair of the BOF.

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 then scheduled by submitting a request to with copies to the Area Director(s). A BOF description and agenda are required before a BOF can be scheduled.

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 assurances before authorizing a BOF. For example,

In general, a BOF on a particular topic is held only once -- ONE slot at one IETF Plenary meeting. Under unusual circumstances Area Directors MAY, at their discretion, allow a BOF to meet for a second time. BOFs are limited to a maximum of two meetings. Note that all other things being equal, WGs will be given priority for meeting space over BOFs. Also, occasionally BOFs might be held for other purposes than to discuss formation of a working group.

Usually the outcome of a BOF will be one of the following:

7.1.3. Charter Development

The formation of a working group requires a charter. Development of a charter results from the efforts of interested parties and an Area Director. The substance of IETF working group charters is specified in Section 7.2. The development of the proposed charter is overseen by a shepherding Area Director and can be pursued in a number of ways.

The method of developing a charter can vary greatly. In many instances, the development of the charter is carried out on an open mailing list, allowing all interested IETF participants to contribute to the effort. Among other possibilities, charter development might driven by a small group of active proponents. All charter development models allow for interested participants to take ownership in the purpose and outcome of the working group.

It is common, but not required, to hold an exploratory Birds of a Feather (BOF) meeting to gauge the level of support for a working group.([RFC5434],Section 7.1.2) Such a BOF can focus on formulating the problem to be solved, considering the key items in a proposed charter, discussing proposed solutions, or some combination of these items.

When the prospective Chair(s), the Area Director and the IETF Secretariat are satisfied with the charter form and content, it becomes the foundation of the working group approval process and for the substantive conduct of the working group.

7.1.4. Charter review & approval

Proposed working groups often include technically competent participants who are not familiar with the history of Internet architecture or IETF processes. This can, unfortunately, lead to good working group consensus about a bad design.

To facilitate working group efforts, an Area Director MAY assign a Adviser from among the ranks of IETF participants. (Section 6)

At the discretion of the Area Director, approval of a new WG MAY be withheld in the absence of sufficient Adviser resources.

For review of a draft charter, the sponsoring Area Director might consult with their Area Directorate, or others, as deemed appropriate. Once an Area Director supports a version of the working group charter, the approval sequence then is:

  1. In parallel:
  2. After a review period of at least a week, in parallel:
  3. After another review period lasting at least a week the IESG MAY approve the charter as-is, or it MAY request that changes be made in the charter, or MAY decline to approve chartering of the working group

If the IESG approves the formation of the working group it remands the approved charter to the IETF Secretariat who records and enters the information into the IETF tracking database. The working group is announced to the IETF-announce a by the IETF Secretariat.

7.1.5. Milestones Revision

The milestone list is expected to be updated periodically. Updated milestones are (re-)negotiated with the Area Director, as needed, and then are submitted to the IESG Secretariat:

7.1.6. Rechartering a Working Group

Charters MAY be renegotiated periodically to reflect the current status, organization or goals of the working group.

Rechartering a working group follows the same procedures that the initial chartering does Section 7.1.

7.2. Charter Content

Charter development and approval, rechartering, and milestone revision are discussed in Section 7.1.

Examples working group charters are shown in Appendix B

A charter consists of the following sections:

Working group name:
A working group name ought to be reasonably descriptive or identifiable. Additionally, the group needs to define an acronym (maximum 8 printable ASCII characters) to reference the group in the IETF directories, mailing lists, and general documents.
The working group can have one or more Chairs to perform the administrative functions of the group. The email address(es) of the Chair(s) are included. Generally, a working group is limited to two chairs.
(Optional) Other Staff:
Optional positions, such as secretary and technical adviser.
Area Director(s):
The name of the IETF area with which the working group is affiliated and the name and electronic mail address of the associated Area Director(s).
Responsible Area:
Director The Area Director who acts as the primary IESG contact for the working group.
Mailing list:
An IETF working group MUST have a general Internet mailing list. The working group charter MUST include:

For basic IETF requirements concerning mailing list configuration and use. (

Section 2.3)
Description of working group:
The focus and intent of the group is set forth briefly. By reading this section alone, an individual should be able to decide whether this group is relevant to their own work.
To facilitate evaluation of the intended work and to provide on-going guidance to the working group, the charter MUST describe the problem being solved and SHOULD discuss objectives and expected impact with respect to:
Goals and milestones:
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 MUST 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.

7.3. Submission & Publication of Documents

Once a WG has determined that rough consensus exists within 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 MUST be in the Internet-Drafts directory, formatted according to Section 3.6
The WG Chair MUST initiate a publication request through the Datatracker entry for the document

The copy of the message to the IESG Secretariat is to ensure that the request gets recorded by the Secretariat so that they can monitor the progress of the document through the process.

Unless returned by the IESG to the WG for further development, progressing of the document is then the responsibility of the IESG.

After IESG approval, responsibility for final disposition is the joint responsibility of the RFC Editor, the WG Chair and the Document Writer.

The Chair and/or Document Editor will work with the RFC Editor to ensure document conformance with RFC publication requirements [RFC2223] 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.

7.4. Working Group Termination

Working groups are typically chartered to accomplish a specific task or tasks. Upon completion of its goals and achievement of its objectives, the working group is usually terminated. (A working group MAY also be terminated for other reasons, as discussed in Section 7.4.>

If there is sufficient community interest the working group will formally become dormant rather than be disbanded -- the WG will no longer conduct formal activities -- so that the mailing list will remain available to review activities related to the working group's topic, including use and issues with documents it has produced.

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 which that work was based have been modified in discussion or by experience, the Area Director, in consultation with the working group can either:

If the working group disagrees with the Area Director's choice, it MAY appeal to the IESG. Section 7.5

7.5. 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 made, and genuine consensus achieved; however, there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, resolution of such conflicts MUST be pursued through a process of open review and discussion.

Formal procedures for requesting a review of WG, Chair, Area Director or IESG actions and conducting appeals are documented in The Internet Standards Process [RFC2026].

8. Security Considerations

9. References

9.1. References - Normative

, ", ", ", ", ", "
[AgendaNotes]Formatting and Content of IETF Working Group Agendas and Minutes", WEB, .
[IETF-Meetings]IETF Meetings", WEB, .
[Interim]Interim Meetings", WEB, .
[MeetMaterialTool]The IETF Meeting Materials Management Tool", WEB, .
[MeetMaterials]Meeting Materials", WEB, .
[MeetRequest]Requesting Meeting Sessions at IETF Meetings", WEB, .
[RFC2026] Bradner, S., The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

9.2. References - Informative

, ", ", ", ", ", ", ", ", ", ", ", "
[AD-Desc]Area Director Qualifications", WEB, .
[Areas]Areas", WEB, .
[ChairGuide]WG Chairs' Guide,", WEB, .
[Facilitate]Facilitation", WEB, .
[I-D]Internet-Drafts (I-Ds)", WEB, .
[I-D-Guidelines] Russ, R., "Guidelines to Authors of Internet-Drafts", WEB, December 2010.
[I-D-Jscribe]The Jabber Scribe Role at IETF Meetings", I-D draft-saintandre-jabber-scribe, .
[IETF]About the IETF", WEB, .
[Interim-Train] Atlas, A., Schliesser, B. and S. Turner, Routing Area Chair Training: Interim Meetings", WEB, January 2015.
[MailList]Email Lists", WEB, .
[RFC-Editor]RFC Editor", WEB, .
[RFC-IETF]Request for Comments (RFC)", WEB, .
[RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and Procedures", RFC 1603, March 1994.
[RFC1796] Huitema, C., Postel, J. and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2418] Bradner, S., IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC5434] Narten, T., "Considerations for Having a Successful Birds-of-a-Feather (BOF) Session", RFC 5434, February 2009.
[RFC7221] Farrel, A. and D. Crocker, "Handling of Internet-Drafts by IETF Working Groups", RFC 7221, April 2014.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S. and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, May 2014.
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, June 2014.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, September 2014.
[Secretaries] Vigoureux, M. and D. King, IETF Working Groups' Secretaries", I-D draft-secretaries-good-practices, November 2014.
[Tao]The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", WEB, .
[WG]Working Groups", WEB, .

Appendix A. Acknowledgements

The original version of this document was developed by Erik Huizer and Dave Crocker. ([RFC1603]) A revised version was edited by Scott Bradner and reviewed by the Poisson Working Group. ([RFC2418]) The current version was prompted by [Secretaries] and the vigorous IETF discussion that ensued. In their typical fashion, the IETF Secretariat staff were extremely helpful in clarifying current IETF administrative practices and rules.

Development of the initial version of this document's revision benefited greatly from thoughtful and diligent comments by: Fred Baker, Brian Carpenter, Brian Haberman, Melinda Shore.

Appendix B. Sample Working Group Charters

Can we get a better example? This example does not completely conform to wg charter requirements, especially for the first paragraph of the description. /d


DNS PRIVate Exchange (dprive)

Group Name:  DNS PRIVate Exchange
Acronym:  dprive
Area:  Internet Area (int)
Charter:   charter-ietf-dprive-01 (Approved)
Chairs:   Tim Wicinski <>
         Warren Kumari <>
Area Director:   Brian Haberman <>
Mailing List Address:
To Subscribe:
Jabber Chat Room Address:

Charter for Working Group

The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
provide confidentiality to DNS transactions, to address concerns
surrounding pervasive monitoring (RFC 7258).

The set of DNS requests that an individual makes can provide an
attacker with a large amount of information about that individual.
DPRIVE aims to deprive the attacker of this information. (The IETF
defines pervasive monitoring as an attack [RFC7258])

The primary focus of this Working Group is to develop mechanisms that
provide confidentiality between DNS Clients and Iterative Resolvers,
but it may also later consider mechanisms that provide confidentiality
between Iterative Resolvers and Authoritative Servers, or provide
end-to-end confidentiality of DNS transactions. Some of the results of
this working group may be experimental. The Working Group will also
develop an evaluation document to provide methods for measuring the
performance against pervasive monitoring; and how well the goal is met.
The Working Group will also develop a document providing example
assessments for common use cases.

DPRIVE is chartered to work on mechanisms that add confidentiality to
the DNS. While it may be tempting to solve other DNS issues while
adding confidentiality, DPRIVE is not the working group to do this.
DPRIVE will not work on any integrity-only mechanisms.

Examples of the sorts of risks that DPRIVE will address can be found
in [draft-bortzmeyer-dnsop-dns-privacy], and include both passive
wiretapping and more active attacks, such as MITM attacks. DPRIVE will
address risks to end-users' privacy (for example, which websites an
end user is accessing).

Some of the main design goals (in no particular order) are:

- Provide confidentiality to DNS transactions (for the querier).

- Maintain backwards compatibility with legacy DNS implementations.

- Require minimal application-level changes.

- Require minimal additional configuration or effort from applications or users

Dec 2014   
WG LC on an problem statement document
Mar 2015   
WG selects one or more primary protocol directions
Jul 2015   
WG LC on primary protocol directions

B.2. iptel

Working Group Name:
IP Telephony (iptel)

IETF Area:
    Transport Area

 Jonathan Rosenberg <>
Transport Area Director(s):
 Scott Bradner <>
 Allyn Romanow <>

Responsible Area Director:
 Allyn Romanow <>

Mailing Lists:
 To Subscribe:

Description of Working Group:

 Before Internet telephony can become a widely deployed service, a
 number of protocols must be deployed. These include signaling and
 capabilities exchange, but also include a number of "peripheral"
 protocols for providing related services.

 The primary purpose of this working group is to develop two such
 supportive protocols and a frameword document. They are:

 1. Call Processing Syntax. When a call is setup between two
 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 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
 can be authored by the user (or generated automatically by some
 tool), and then uploaded to the server. The group will develop this
 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
 describes the services that are enabled by the call processing
 syntax, and discusses how the syntax can be used. This document will
 result in a single RFC.

 3. Gateway Attribute Distribution Protocol. When making a call
 between an IP host and a PSTN user, a telephony gateway must be used.
 The selection of such gateways can be based on many criteria,
 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

Goals and Milestones:
 May 98 Issue first Internet-Draft on service framework
 Jul 98 Submit framework ID to IESG for publication as an RFC.
 Aug 98 Issue first Internet-Draft on Call Processing Syntax
 Oct 98 Submit Call processing syntax to IESG for consideration
     as a Proposed Standard.
 Dec 98 Achieve consensus on basics of gateway attribute
        distribution protocol
 Jan 99 Submit Gateway Attribute Distribution protocol to IESG
        for consideration as a RFC (info, exp, stds track TB

B.3. rtg

Working Group Name:   Routing Over Low power and Lossy networks
Acronym:  roll
Area:  Routing Area (rtg)
Charter:   charter-ietf-roll-03 (Approved)
Chairs:   Ines Robles <>
         Michael Richardson <>
Area Director:   Adrian Farrel <>
Tech Advisor:   Rene Struik <>
Delegates:   Robert Cragie <>
Yvonne-Anne Pignolet <>
Mailing List Address:
To Subscribe:
Jabber Chat Room Address:

Charter for Working Group

Low power and Lossy networks (LLNs) are made up of many
embedded devices with limited power, memory, and processing
resources. They are interconnected by a variety of links, such as
IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low
power PLC (Powerline Communication) links. LLNs are transitioning
to an end-to-end IP-based solution to avoid the problem of
non-interoperable networks interconnected by protocol translation
gateways and proxies.

Generally speaking, LLNs have at least five distinguishing
- LLNs operate with a hard, very small bound on state.
- In most cases, LLN optimize for saving energy.
- Typical traffic patterns are not simply unicast flows (e.g. in some
  cases most if not all traffic can be point to multipoint)
- In most cases, LLNs will be employed over link layers with
  restricted frame-sizes, thus a routing protocol for LLNs should be
  specifically adapted for such link layers.
- LLN routing protocols have to be very careful when trading off
  efficiency for generality; many LLN nodes do not have resources to

These specific properties cause LLNs to have specific routing

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have
been evaluated by the working group and have in their current form been
found to not satisfy all of these specific routing requirements.

The Working Group is focused on routing issues for LLN.

There is a wide scope of application areas for LLNs, including
industrial monitoring, building automation (HVAC, lighting, access
fire), connected homes, healthcare, environmental monitoring, urban sensor
networks (e.g. Smart Grid), asset tracking. The Working Group focuses
on routing solutions for a subset of these: industrial, connected
home, building and urban sensor networks for which routing requirements have
been specified. These application-specific routing requirement
documents will be used for protocol design.

The Working Group focuses only on IPv6 routing architectural framework
for these application scenarios. The Framework will take into
consideration various aspects including high reliability in the presence
of time
varying loss characteristics and connectivity while permitting low-power
operation with very modest memory and CPU pressure in networks
potentially comprising
a very large number (several thousands) of nodes.

The Working Group will pay particular attention to routing security
and manageability (e.g., self routing configuration) issues. It will
also need to consider the transport characteristic the routing protocol
messages will experience. Mechanisms that protect an LLN from congestion
collapse or
that establish some degree of fairness between concurrent
communication sessions are out of scope of the Working Group. It is
expected that
upper-layer applications utilizing LLNs define appropriate mechanisms.
The solution must include unicast and multicast considerations.

Work Items:

- Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for routing in

- Provide an architectural framework for routing and path selection at
Layer 3 (Routing for LLN Architecture) that addresses such issues as
whether LLN routing require a distributed and/or centralized path
computation models, whether additional hierarchy is necessary and how it

Manageability will be considered with each approach, along with
various trade-offs for maintaining low power operation, including the
presence of non-trivial loss and networks with a very large number of nodes.
- Produce a routing security framework for routing in LLNs.

- Protocol work: The Working Group will consider specific routing
requirements from the four application documents collectively, and
specify either
a new protocol or extend an existing routing protocol in cooperation
with the
relevant Working Group.
If requirements from the four target application areas cannot be met
with a single protocol, the WG may choose to specify or extend more than
protocol (this will require a recharter of the WG).

- Documentation of applicability statement of ROLL routing protocols.

Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC.
Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC.
Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC.
Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC.
Submit Security Framework to the IESG to be considered as an Informational RFC
Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard.
Submit first draft of ROLL routing protocol specification as Proposed Standard.
Submit the ROLL routing protocol specification to the IESG as Proposed Standard.
Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC
WG to adopt RPL applicability statement Home for Automation applications
WG to adopt RPL applicability statement(s) for AMI networks
WG to adopt RPL applicability statement for Industrial applications
WG to adopt reviewed template for applicability statements
Resolve question of whether to keep this in roll or 6tisch
submit REVISED thread-analysis document based upon security directorate review to IESG.
Feb 2014   
Submit first draft of RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC
Evaluate WG progress, recharter or close
Aug 2014   
WG to joint-LC using flow-label for RPL with 6man

B.4. another one

Appendix C. [PROTO-WIKI] Working Group Advice

Prior to publication, this section is to be moved to an IETF wiki page, for on-going enhancement.
ALSO: The document's reference to this section needs to be modified to refer to that wiki.

C.1. If you have a formal WG role...

Here is some basic advice to anyone performing working group administrative or management dutues -- that is, anyone assigned tasks by the AD or a chair:

C.2. Advice for Chairs

C.3. Meetings

C.3.1. WG meeting preparation

C.3.1.1. Request meeting slot(s)

A WG will typically meet once during an IETF meeting. The chairs may choose to request two slots if the WG has a long agenda. Requesting more than two slots requires approval of the Area Director.

The request will include the expected length, number of participants and a list of other WGs with which time conflicts should be avoided. These specific requests should be considered carefully as they are important for successful scheduling.

C.3.1.2. Create and post agenda

Well before the meeting, the WG administration posts a request for proposed discussion items, presentations and other agenda items to the WG mailing list.

The WG administration collects the requests for agenda items and adds other agenda items as required for WG operation and posts a draft agenda for WG review. Once the final agenda is ready, the WG administration posts it through the IETF Meeting Materials manager web page.

C.3.1.3. Post meeting materials

Any documents to be discussed at the WG meeting must be posted two weeks before the meeting. The IESG Secretariat enforces an I-D publication restriction during the two weeks before the IETF meeting.

Any presentations or other materials should be posted through to the IETF Meeting Materials at least a week before the IETF meeting to provide participants an opportunity to review those materials.

C.3.1.4. Other meeting prep

There are minute takers and jabber scribes at every WG meeting. It can save time at the meeting to identify individuals to fill those roles prior to the meeting.

C.3.2. WG meeting operation

C.3.3. WG Meeting Followup

C.4. Ongoing WG operation

C.4.1. Managing Individual Documents

Documents typically go through several revisions in the process of WG development and review. The datatracker is used to manage and publish the state of an I-D as it progresses toward publication. WG administration coordinates the editing of the document by the editors with the input from the WG. The issues tracker is a useful tool for recording and managing specific issues with an I-D.

The document shepherd manages the processing and publication of the document after it has been submitted by the WG to the IESG for publication. The issues tracker can be useful at this stage of the publication process as well.

C.4.2. Charter Management

Authors' Addresses

Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA Phone: +1.408.246.8253 EMail:
Ralph Droms (editor) Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: