| 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
draft-crocker-rfc2418bis-wgguidelines-00
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.
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 http://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 September 10, 2015.
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 (http://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 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.
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.
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.
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].
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.
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.
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
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.
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.
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).
{ACRONYM}-archive@ietf.org
Mailing lists related to IETF activities are usually hosted at the IETF, but generally MAY be hosted elsewhere.
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:
http://www.ietf.org/mail-archive/web/{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.
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.
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.
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.
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.
http://datatracker.ietf.org/wg/{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:
http://trac.tools.ietf.org/wg/{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:
http://trac.tools.ietf.org/wg/{ACRONYM}/trac/report
One can be provided through the working group wiki, if requested by a Chair, at the tab for "View Tickets":
Any organized working group session (meeting) will have planning and reporting material, including:[MeetMaterials], [MeetMaterialTool].
Details about IETF Meeting Materials are provided in
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].
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]
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)
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.
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.
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).
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).
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.
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.
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:
It is also good practice to:
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.
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.
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.
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.
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.
Other methods of mailing list control MAY be considered but MUST be approved by the AD(s) and the IESG.
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.
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 Chair SHOULD consult with the Area Director(s) if the individual persists in disruptive behavior.
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.
Administrative and process details for the conduct of structured meetings are referenced at [IETF-Meetings] and in [Interim]
[MeetMaterials], [MeetMaterialTool].
Details about Meeting Materials are provided in
The task(s) of creating records about meeting activity are discussed in [AgendaNotes], above.
Working groups produce documents and documents need Writers.
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.
Working group development of a document proceeds through these steps:
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.
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.
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])
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:
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].
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.
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.
When determining whether it is appropriate to create a working group, the Area Director(s) and the IESG will consider several issues:
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.
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 agenda@ietf.org 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:
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.
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.
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:
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.
iesg-secretary@ietf.org
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:
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.
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:
For basic IETF requirements concerning mailing list configuration and use. (
Section 2.3)
Once a WG has determined that rough consensus exists within the WG for the advancement of a document, the following MUST be done:
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.
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
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].
| [AgendaNotes] | Formatting and Content of IETF Working Group Agendas and Minutes", WEB http://www.ietf.org/wg/agenda-minutes-procedures.html, . | , "
| [IETF-Meetings] | IETF Meetings", WEB http://www.ietf.org/meeting/, . | , "
| [Interim] | Interim Meetings", WEB http://www.ietf.org/meeting/interim-meetings.html, . | , "
| [MeetMaterialTool] | The IETF Meeting Materials Management Tool", WEB http://www.ietf.org/old/2009/instructions/meeting_materials_tool.html, . | , "
| [MeetMaterials] | Meeting Materials", WEB http://www.ietf.org/wg/meeting-materials.html, . | , "
| [MeetRequest] | Requesting Meeting Sessions at IETF Meetings", WEB http://www.ietf.org/old/2009/instructions/MTG-SLOTS.html, . | , "
| [RFC2026] | Bradner, S., The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. |
| [AD-Desc] | Area Director Qualifications", WEB http://trac.tools.ietf.org/group/iesg/trac/wiki/AreasDescription, . | , "
| [Areas] | Areas", WEB https://www.ietf.org/iesg/area.html, . | , "
| [ChairGuide] | WG Chairs' Guide, http://wiki.tools.ietf.org/group/wgchairs/", WEB http://wiki.tools.ietf.org/group/wgchairs/, . | , "
| [Facilitate] | Facilitation", WEB http://en.wikipedia.org/wiki/Facilitation_%28business%29, . | , "
| [I-D] | Internet-Drafts (I-Ds)", WEB https://www.ietf.org/id-info/, . | , "
| [I-D-Guidelines] | Russ, R., "Guidelines to Authors of Internet-Drafts", WEB https://www.ietf.org/id-info/guidelines.html, December 2010. |
| [I-D-Jscribe] | The Jabber Scribe Role at IETF Meetings", I-D draft-saintandre-jabber-scribe, . | , "
| [IETF] | About the IETF", WEB http://www.ietf.org/about/, . | , "
| [Interim-Train] | Atlas, A., Schliesser, B. and S. Turner, Routing Area Chair Training: Interim Meetings", WEB https://tools.ietf.org/area/rtg/trac/raw-attachment/wiki/WGChairTraining/rtgwg_train_4.pdf, January 2015. |
| [MailList] | Email Lists", WEB http://www.ietf.org/list/, . | , "
| [RFC-Editor] | RFC Editor", WEB http://www.rfc-editor.org/, . | , "
| [RFC-IETF] | Request for Comments (RFC)", WEB http://www.ietf.org/rfc.html, . | , "
| [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 http://www.ietf.org/tao.html, . | , "
| [WG] | Working Groups", WEB http://www.ietf.org/wg/, . | , "
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.
DNS PRIVate Exchange (dprive)
Group Name: DNS PRIVate Exchange
Acronym: dprive
Area: Internet Area (int)
Charter: charter-ietf-dprive-01 (Approved)
Personnel
Chairs: Tim Wicinski <tjw.ietf@gmail.com>
Warren Kumari <warren@kumari.net>
Area Director: Brian Haberman <brian@innovationslab.net>
Mailing List Address: dns-privacy@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy
Archive: http://www.ietf.org/mail-archive/web/dns-privacy/
Jabber Chat Room Address: xmpp:dprive@jabber.ietf.org
Logs: http://jabber.ietf.org/logs/dprive/
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
Milestones
Dec 2014
WG LC on an problem statement document
draft-bortzmeyer-dnsop-dns-privacy
Mar 2015
WG selects one or more primary protocol directions
Jul 2015
WG LC on primary protocol directions
Working Group Name:
IP Telephony (iptel)
IETF Area:
Transport Area
Chair(s):
Jonathan Rosenberg <jdrosen@bell-labs.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Responsible Area Director:
Allyn Romanow <allyn@mci.net>
Mailing Lists:
General Discussion:iptel@lists.research.bell-labs.com
To Subscribe: iptel-request@lists.research.bell-labs.com
Archive: http://www.bell-labs.com/mailing-lists/siptel
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 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
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
appropriate.
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
Working Group Name: Routing Over Low power and Lossy networks
Acronym: roll
Area: Routing Area (rtg)
Charter: charter-ietf-roll-03 (Approved)
Personnel
Chairs: Ines Robles <maria.ines.robles@ericsson.com>
Michael Richardson <mcr+ietf@sandelman.ca>
Area Director: Adrian Farrel <adrian@olddog.co.uk>
Tech Advisor: Rene Struik <rstruik.ext@gmail.com>
Delegates: Robert Cragie <robert.cragie@gridmerge.com>
Yvonne-Anne Pignolet <yvonneanne.pignolet@gmail.com>
Mailing List Address: roll@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/roll
Archive: http://www.ietf.org/mail-archive/web/roll/
Jabber Chat Room Address: xmpp:roll@jabber.ietf.org
Logs: http://jabber.ietf.org/logs/roll/
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
characteristics:
- 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
waste.
These specific properties cause LLNs to have specific routing
requirements.
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
control,
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
LLNs.
- 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
is
applied.
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.
should
- 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
one
protocol (this will require a recharter of the WG).
- Documentation of applicability statement of ROLL routing protocols.
Milestones
Done
Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC.
Done
Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC.
Done
Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC.
Done
Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC.
Done
Submit Security Framework to the IESG to be considered as an Informational RFC
Done
Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard.
Done
Submit first draft of ROLL routing protocol specification as Proposed Standard.
Done
Submit the ROLL routing protocol specification to the IESG as Proposed Standard.
Done
Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC
Done
WG to adopt RPL applicability statement Home for Automation applications
draft-ietf-roll-applicability-home-building
Done
WG to adopt RPL applicability statement(s) for AMI networks
draft-ietf-roll-applicability-ami
Done
WG to adopt RPL applicability statement for Industrial applications
draft-ietf-roll-rpl-industrial-applicability
Done
WG to adopt reviewed template for applicability statements
draft-ietf-roll-applicability-template
Done
Resolve question of whether to keep this in roll or 6tisch
draft-ietf-roll-rpl-industrial-applicability
Done
submit REVISED thread-analysis document based upon security directorate review to IESG.
draft-ietf-roll-security-threats
Feb 2014
Submit first draft of RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC
Done
Evaluate WG progress, recharter or close
Aug 2014
WG to joint-LC using flow-label for RPL with 6man
draft-thubert-6man-flow-label-for-rpl
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:
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.
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.
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.
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.
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.