One document matched: draft-crocker-rfc2418bis-wgguidelines-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc strict="no"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc inline="yes"?>
<?rfc topblock="yes" ?>
<?rfc autobreaks="yes" ?>
<rfc category="bcp" docName="draft-crocker-rfc2418bis-wgguidelines-00"
ipr="trust200902" obsoletes="2418, 7221" updates="2026">
<front>
<title abbrev="WG Guidelines & Procedures">IETF Working Group
Guidelines and Procedures</title>
<author fullname="Dave Crocker" initials="D." role="editor"
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author fullname="Ralph Droms" initials="R." role="editor"
surname="Droms">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Massachusetts Avenue</street>
<city>Boxborough</city>
<code>01719</code>
<region>MA</region>
</postal>
<email>rdroms@cisco.com</email>
</address>
</author>
<date day="" month="" year="2015" />
<keyword>IETF working group process charter chair area director design
team </keyword>
<abstract>
<t> 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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<!-- Sessions: f2f, -->
<t>The <xref target="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 <xref target="WG">Working Groups</xref>. For
administrative purposes, they are organized into topical <xref
target="Areas" />. Working groups are formally chartered,
typically with a narrow focus and lifetime bounded by the
completion of a specific set of tasks. </t>
<t>This document describes the formation, requirements, structure,
and operation of IETF working groups. This includes the formal
relationships and duties of participants.</t>
<t>At base, working groups are driven by:<list style="symbols">
<t>Goals</t>
<t>Rules</t>
<t>Tasks</t>
<t>Participants</t>
</list> 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.</t>
<section title="Background">
<t>This version is organized as an aid to (new) working group
participants both as an introduction and as a later reference.
<list style="symbols">
<t>It describes existing IETF rules and practices and does
not describe or suggest any changes.</t>
</list></t>
<t>Specifically this version of the document: <list
style="symbols">
<t>Replaces general IETF tutorial material that it had with
pointers to independent versions</t>
<t>Incorporates work from a number of targeted efforts over
the years</t>
<t>Reorganizes content to aid direct use by working group
participants</t>
<t>Distinguishes between formal IETF requirements and
processes, versus common practices chosen by working
groups, where the latter are primarily discussed in a
non-normative <xref target="WG-Advice">external IETF
Wiki</xref> that can be continually revised by the
community.</t>
</list></t>
<t>A useful introduction to the IETF is <xref target="Tao">The Tao
of IETF: A Novice's Guide to the Internet Engineering Task
Force</xref>. Familiarity with <xref target="RFC2026">The
Internet Standards Process</xref> is essential for a
complete understanding of the philosophy, procedures and
guidelines described in this document. </t>
</section>
<section anchor="Terms" title="Terminology and References">
<t>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 <xref target="RFC2119" />.</t>
<t><list style="hanging">
<t hangText="NOTE: ">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.</t>
</list></t>
<t>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 <xref target="Roles" />.</t>
</section>
<section title="OPEN ISSUES">
<t><list>
<t><list style="hanging">
<t hangText="NOTE TO RFC EDITOR: ">Remove this section
before publication.</t>
</list></t>
</list>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.</t>
<t><list style="hanging">
<t hangText="Roles/Titles: ">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?</t>
<t hangText="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. </t>
<t hangText="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.</t>
<t hangText="Familiarity: ">Besides RFC 2026, what other
IETF docs are "required" for the reader to have
familiarity with?</t>
<t hangText="Charter negotiation: ">WHO NEGOTIATES A
CHARTER??? Distinguish required vs. flexible. Emphasize
open and accountable.</t>
<t hangText="Citations: ">What other RFCs, IESG Statements,
etc. need to be cited?</t>
<t hangText="Mailing List Hosting: ">(Secretariat queried)
Are IETF working group mailing lists now required to be
hosted at the IETF?</t>
<t hangText="Milestones: ">make sure example charter in
Appendix A includes milestones</t>
<t hangText="Suspension: ">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?</t>
<t hangText="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)."</t>
<t hangText="Wiki? ">What should be moved to the Wiki or
added to it?</t>
<t hangText="Normative?">Review references for
normative/non-normative placement listing in doc.</t>
<t hangText="Reporting? ">Resolve various IETF website
pages concerning submission and archive of notes,
etc?</t>
<t hangText="Milestone Revision: ">Revised milestones MUST
be approved by the cognizant Area Director. Is any other
review or approval needed, such as from the IESG?</t>
</list></t>
</section>
</section>
<section title="Basic Structure and Requirements">
<t>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.</t>
<section title="Working Group Charter">
<t>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: <list style="symbols">
<t>Lists relevant administrative information for the working
group</t>
<t>Specifies the direction or objectives of the working
group and describes the approach that will be taken to
achieve the goals</t>
<t>Enumerates a set of milestones together with time frames
for their completion</t>
</list>Details concerning charters are provided in <xref
target="CharterContent" />.</t>
</section>
<section title="Deliverables">
<t>A working group's charter specifies deliverables to be
achieved. (<xref target="CharterContent" />) These are usually
documents to be published in the Request for Comments series
<xref target="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.</t>
<t>In other words, the group needs to efficiently balance fair and
open discussion, proper attention to legitimate concerns, and
making forward progress.</t>
</section>
<section anchor="Lists" title="Mailing List">
<t>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. (<xref target="CharterContent" />) Further, the
mailing list MUST be the only venue for formally assessing
working group rough consensus. <list>
<t>"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.</t>
</list></t>
<t><list style="hanging">
<t hangText="(Task) ">It is important to ensure that the
discussions on this list are relevant and that they
converge to consensus agreements.</t>
<t hangText="(Task) ">It can help to summarize a discussion
periodically.</t>
<t hangText="(Task) ">It also can help later review to
ensure that outcomes are well and explicitly documented
(to avoid repetition).</t>
</list></t>
<t> 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). </t>
<t>Mailing lists related to IETF activities are usually hosted at
the IETF, but generally MAY be hosted elsewhere. <list
style="hanging">
<t hangText="(Task) ">A message archive MUST be maintained
in a public place which can be accessed via FTP or via
the web.</t>
</list> 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:<figure>
<artwork align="center">{ACRONYM}-archive@ietf.org</artwork>
</figure> (where {ACRONYM} is the abbreviated name for the
working group) in the mailing list, so that a copy of all
mailing list messages is recorded in the Secretariat's archive
for the list.</t>
<t> Multiple versions of list archives are available, as indicated
in the "Archives" section of <xref target="MailList" />. One
form is located at:<figure>
<artwork align="center">http://www.ietf.org/mail-archive/web/{ACRONYM}/current/maillist.html</artwork>
</figure> where {ACRONYM} is the abbreviated name for the
working group. For robustness, WGs SHOULD maintain an
additional archive separate from that maintained by the
Secretariat. </t>
</section>
<section anchor="AD" title="Area Directors">
<t>IETF Working Groups are administratively aggregated into
"areas". Each working group has a designated ("cognizant") Area
Director [AD] (<xref target="AD-Desc" />,<xref target="Areas"
/>), to formally select chairs for the working group and to
provide oversight.</t>
</section>
<section anchor="Chair" title="Chair(s)">
<t>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 <xref target="Consensus"
>rough consensus</xref> 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.</t>
<t>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.</t>
<t>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. </t>
</section>
<section anchor="Writer" title="Document Writer">
<t>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.</t>
<t>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.</t>
<t>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
<xref target="RFC7221" /> for a suggested distinction
between primary responsibility for creating concepts and
content, versus responsibility for recording content developed
by the working group itself. </t>
</section>
<section anchor="Participants" title="Participants">
<t>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.</t>
<t><list style="hanging">
<t hangText="NOTE: "> WG participants MUST conform to the
requirements for disclosure of conflicts of interest in
<xref target="RFC2028" />.</t>
</list></t>
</section>
<section anchor="Consensus" title="Rough Consensus Decision Making">
<t>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 <xref
target="RFC7282">Rough Consensus</xref>. Within working
group processes, this is the required means for making working
group decisions, but more importantly it is a model for
considering issues.</t>
<t><list style="hanging">
<t hangText="Expediency: ">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.</t>
<t hangText="Substantiveness: ">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. </t>
<t hangText="Minorities: ">The other major challenge, as
discussed in <xref target="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.</t>
</list>
</t>
</section>
</section>
<section anchor="Docs" title="Documents">
<section title="Home Page">
<t>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: <figure>
<artwork align="center"><![CDATA[http://datatracker.ietf.org/wg/{ACRONYM}/documents/]]></artwork>
</figure>where {ACRONYM} is the abbreviated name for the
working group.</t>
</section>
<section anchor="Wiki" title="Wiki">
<t>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:<figure>
<artwork align="center"><![CDATA[http://trac.tools.ietf.org/wg/{ACRONYM}/trac/wiki]]></artwork>
</figure>where {ACRONYM} is the abbreviated name for the
working group.</t>
</section>
<section anchor="Tickets" title="Issue-tracking Tickets">
<t><list style="hanging">
<t hangText="(Task) ">As topics, issues and suggestions
increase for a working group, it can be helpful to
document them in an issue tracking system.</t>
</list></t>
<t>One can be provided through the working group wiki, if
requested by a Chair, at the tab for "View Tickets":<figure>
<artwork align="center"><![CDATA[http://trac.tools.ietf.org/wg/{ACRONYM}/trac/report]]></artwork>
</figure>where {ACRONYM} is the abbreviated name for the
working group.</t>
</section>
<!--
<section anchor="Notes" title="Meeting Notes">
<t><list style="hanging">
<t hangText="(Task) ">When a working group conducts a
meeting, it MUST formulate notes about presentations,
discussion, issues, and consensus calls.</t>
</list></t>
<t>The form of these notes can vary widely and a meeting often
produces more than one form, such as a near-transcript, a chat
log, and the formally-submitted summary review. (<xref
target="AgendaNotes" />)</t>
<t>Summary review notes/minutes SHOULD include <list
style="symbols">
<t>The agenda for the session</t>
<t>An account of the discussion including any meeting
consensus assessments</t>
<t>A list of attendees</t>
</list>The minutes MUST be submitted in printable ASCII text
for publication in the IETF Proceedings, and for posting in the
IETF Directories and are to be sent to: <figure>
<artwork align="center"><![CDATA[minutes@ietf.org]]></artwork>
</figure></t>
</section>-->
<section anchor="MeetingStuff" title="Meeting Materials">
<t>Any organized working group session (meeting) will have
planning and reporting material, including:<list
style="symbols">
<t>Agenda</t>
<t>Presentations</t>
<t>Notes</t>
<t>Transcripts (e.g., jabber logs)</t>
</list>
<list style="hanging">
<t hangText="(Task) ">The planning and presentation
material needs to be made available in advance of the
session.</t>
<t hangText="(Task) ">They and the reporting materials also
need to be preserved for later reference. </t>
</list>Details about IETF Meeting Materials are provided in
<xref target="MeetMaterials" />, <xref
target="MeetMaterialTool" />. </t>
<t>
<list style="hanging">
<t hangText="NOTE: ">The IETF web site has related
information that appears to be out of date, such as <xref
target="AgendaNotes" />.</t>
</list></t>
</section>
<section anchor="WG-ID" title="Internet-Drafts (I-D)">
<!-- Might start as indiv effort; when adopted by wg, it become wg property.
-->
<t>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 <xref target="I-D">Internet Drafts</xref>,
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.</t>
<t>Formal adoption of Internet Drafts in a working group is
discussed in <xref target="RFC7221" />. Also, there are naming
conventions, to identify Internet Drafts that have been adopted
by a working group, as described in Section 7 of <xref
target="I-D-Guidelines" />.</t>
</section>
<section anchor="RFC" title="Request For Comments (RFC)">
<t>The work of an IETF working group typically targets publication
of one or more documents, as part of the Request For Comments
(RFC) series. (<xref target="RFC-IETF" />, <xref
target="RFC-Editor" />, <xref target="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. <xref target="RFC7322" /></t>
<t>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. <xref
target="RFC1796" /></t>
</section>
</section>
<section title="Working Group Internal Operation">
<section title="Prime Directives">
<t>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. </t>
<t><list style="symbols">
<t>The core rule for operation is that acceptance or
agreement is achieved via working group "rough
consensus". (<xref target="Consensus" />)</t>
</list></t>
<t>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.</t>
<t>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 (<xref target="Roles" />). These are
discussed at length in the associated wiki. (<xref
target="WG-Advice" />) <list style="hanging">
<t hangText="(Task) ">Actual choices for the details of
working group operation are determined by the working
group participants and the Chair(s).</t>
</list></t>
<t hangText="Ensure WG process and content management "> 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. (<xref
target="Roles" />)</t>
<t hangText="Distribute the workload ">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.</t>
</section>
<section title="General Organizing">
<t>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.</t>
<section title="Characterizing the Effort">
<t><list style="hanging">
<t hangText="(Task) ">It can help to evaluate the work
to be done and the participation in the working group
that will do it: <list style="symbols">
<t>Consider the community knowledge of the problem
space</t>
<t>Consider the plausible solution space, in terms
of complexity and clarity</t>
<t>Consider the composition of the working group,
in terms of size, shared knowledge, interaction
style, and focus on achieving productive
results</t>
</list></t>
</list>
</t>
</section>
<section title="Plan of Work">
<t>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).</t>
<t><list style="hanging">
<t hangText="(Task) ">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 <xref target="Wiki">
Wiki.</xref></t>
</list></t>
</section>
<section title="Tasks vs. Roles">
<t>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. </t>
<t>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 (<xref target="Roles"
/>).</t>
</section>
<section title="Venues">
<t>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.)</t>
<t>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: <xref target="Venues" />, <xref target="SessionPlan"
/>, <xref target="Interims" />.</t>
</section>
</section>
<section title="Discussion and Progress">
<t> 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. <list style="hanging">
<t hangText="(Task) ">The Chair has the responsibility for
overseeing the process but MAY delegate direct process
management to a formally-designated Facilitator.</t>
</list>
</t>
<t>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: <list
style="hanging">
<t hangText="(Task) ">Main arguments in the discussion (and
the outcome) are summarized and archived after a
discussion has come to conclusion.</t>
</list> It is also good practice to: <list style="hanging">
<t hangText="(Task) ">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.</t>
</list>
</t>
<t><list style="hanging">
<t hangText="(Task) ">To facilitate making forward
progress, a working group MAY decide to reject or defer
the input from a participant, based upon the following
criteria: <list>
<t><list style="hanging">
<t hangText="Old: ">The input pertains to a
topic that already has been resolved and is
redundant with information previously
available;</t>
<t hangText="Minor: ">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; </t>
<t hangText="Timing: ">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.</t>
</list></t>
</list>
</t>
</list></t>
</section>
<section title="IETF Open Decision-Making">
<t>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. <list>
<t>For the IETF, that means that the official venue for
working group formal decision-making MUST be the mailing
list associated with the group AND NOWHERE ELSE. </t>
</list></t>
<t>Working groups make decisions through a <xref
target="Consensus">"rough consensus" process</xref>, 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 <xref target="RFC7282" />.</t>
<t>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. </t>
<t><list style="hanging">
<t hangText="(Task) ">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.</t>
</list></t>
</section>
<section title="Mailing List Primacy">
<t>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).</t>
<t>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.</t>
<t>An example method is to post a note summarizing: <list
style="symbols">
<t>the discussion</t>
<t> the proposed resolution</t>
<t> the rationale for proposing its adoption</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="Venues" title="Discussion Venues">
<t>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. <list style="hanging">
<t hangText="(Task) ">Remember that consensus reached
during an interactive MUST be reviewed on the mailing
list.</t>
</list></t>
<section title="Tradeoffs">
<t>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.</t>
<t>However there tends to be a significant tradeoff between
doing work at interactive sessions, versus working group
inclusiveness.</t>
<t>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.</t>
<t>If the meetings are face-to-face, the schedule and monetary
demands are dramatically higher and, obviously, further
restrict participation.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t><list>
<t>The mode of interaction can (and probably ought) be
different in different situations. Regardless, the
choice of operational style MUST be made through rough
consensus of all working group mailing list
participants. In determining the balance, the working
group MUST ensure that its process does not serve to
exclude substantive contribution by email-only
participants.</t>
</list></t>
<t>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.</t>
<t>Similarly, "virtual" interim meetings in which all
participants are remote MUST NOT be discriminatory against
those unable to attend.</t>
<t><list>
<t>The choice of operational style MUST be made by the
working group itself.</t>
<t>Again: consensus reached during an interactive session
is purely preliminary. The proposed decision and its
basis MUST be reviewed on the mailing list, and rough
consensus developed and documented there.</t>
</list></t>
</section>
<section anchor="Email" title="Mailing List Discussion Management">
<t>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.</t>
<t>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. </t>
<t> As with face-to-face sessions occasionally a participant
might engage in behavior on a mailing list which disrupts
the WG's progress. <list style="hanging">
<t hangText="(Task) ">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.</t>
</list><list style="hanging">
<t hangText="(Task) "> 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.</t>
</list> Other methods of mailing list control MAY be
considered but MUST be approved by the AD(s) and the
IESG.</t>
</section>
<section anchor="IETFMeeting" title="IETF Plenary Meetings">
<t>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.</t>
<t><list style="hanging">
<t hangText="(Task) ">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. <list style="hanging">
<t hangText="(Task) ">Requirements and procedures
for obtaining a session slot at an IETF Meeting
are specified in <xref target="MeetRequest"
/>.</t>
</list></t>
</list></t>
<t>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. <list style="hanging">
<t hangText="(Task) ">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. </t>
</list>The Chair SHOULD consult with the Area Director(s) if
the individual persists in disruptive behavior.</t>
</section>
<section anchor="Interims" title="Interim Meetings">
<t>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. </t>
<t> Guidance for the conduct of such sessions is provided by
<xref target="Interim" />, with useful tutorial material
at <xref target="Interim-Train" />. Also see: <xref
target="SessionPlan" />.</t>
</section>
</section>
<section anchor="SessionPlan" title="Session Planning">
<t>Administrative and process details for the conduct of
structured meetings are referenced at <xref
target="IETF-Meetings" /> and in <xref target="Interim"
/></t>
<t><list style="hanging">
<t hangText="(Task) ">Sessions MUST be planned, organized
and announced well in advance.</t>
</list></t>
<t><list style="hanging">
<t hangText="(Task) ">For coordinated, structured WG
interactions, a draft agenda SHOULD be published well in
advance of the actual session.</t>
</list> Details about Meeting Materials are provided in <xref
target="MeetMaterials" />, <xref target="MeetMaterialTool"
/>. </t>
</section>
<section anchor="SessionDocs" title="Meeting Drafts and Documents">
<t><list style="hanging">
<t hangText="NOTE: ">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.</t>
</list></t>
<t><list style="hanging">
<t hangText="(Task) "> 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.
<!--To be discussed at the session, any document which does not meet this publication
deadline MUST obtain the specific approval of the working group chair(s).--></t>
</list>
</t>
</section>
<section anchor="Records" title="Meeting Record Keeping">
<t><list style="hanging">
<t hangText="NOTE: ">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.</t>
</list></t>
<t>The task(s) of creating records about meeting activity are
discussed in <xref target="AgendaNotes" />, above.<list
style="hanging">
<t hangText="(Task) ">An attendance list MUST be
circulated</t>
<t hangText="(Task) ">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</t>
<t hangText="(Task) "> 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.</t>
</list></t>
</section>
</section>
<section title="Document Development & Lifecycle">
<t hangText=""> Working groups produce documents and documents need
Writers. <list style="hanging">
<t hangText="(Task) ">The Chair MUST make sure that Document
Writers incorporate changes as agreed to by the WG. </t>
</list>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.</t>
<section anchor="docSequence" title="Basic Sequence">
<t>Working group development of a document proceeds through these
steps: <list style="numbers">
<t>An individual or a group has something for the WG to
discuss and publishes a document on the topic as an
individual I-D</t>
<t>WG adopts the document as a WG work item, per section 2
of <xref target="RFC7221" /></t>
<t>WG develops the document, per <xref target="RFC7221"
/></t>
<t>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</t>
<t>Chairs assign a document shepherd who prepares the cover
sheet and assumes responsibility for managing the review
and publication process</t>
<t>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]</t>
<t>Area Director reviews the document to determine if the
standards action should proceed; this review may include
an external review, per <xref target="RFC2026" /></t>
<t>Area Director formally requests an IETF Last Call to
determine IETF consensus about whether the I-D is ready
for publication, per <xref target="RFC2026" /></t>
<t>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</t>
<t>The AD schedules the I-D for discussion during an IESG
telechat</t>
<t>Prior to the telechat, IESG members post a ballot
position on the I-D</t>
<t>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</t>
<t>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 </t>
</list></t>
</section>
<section title="Early Document Review">
<t>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.</t>
</section>
<section anchor="CrossDoc"
title="Document Coordination Between Working Groups">
<t>A document is adopted by one working group as a deliverable;
they are therefore responsible for its development, review and
publication. (<xref target="WG-ID" />) 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.</t>
<t>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 <xref target="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. </t>
</section>
<section title="Working Group Last-Call">
<t> 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. (<xref target="RFC2026" />)</t>
</section>
<section title="Final External Review of Documents">
<t> 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.</t>
<t>Prior to the IESG beginning their deliberations on
standards-track documents, IETF Secretariat will issue a
"Last-Call" to the IETF mailing list. (<xref target="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.</t>
<t>The IESG review takes into account responses to the Last-Call
and will lead to one of these possible conclusions: <list
style="numbers">
<t>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.</t>
<t>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 <xref target="RFC2026" /> for more
details.)</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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 <xref target="RFC2026" />.</t>
</section>
</section>
<section anchor="Roles" title="Staff Roles">
<t>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.</t>
<t>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. </t>
<t> 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.</t>
<t><xref target="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. </t>
<section title="Development">
<t><list style="hanging">
<t hangText="Document Writer: ">This role is discussed in
<xref target="Writer" />.</t>
<t anchor="DT" hangText="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.</t>
<t hangText="Participant: ">Discuss issues. Suggest ideas
and text. Review documents. Actively pursue resolution of
topics.</t>
</list></t>
</section>
<section title="Advice">
<t><list style="hanging">
<t hangText="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.</t>
</list></t>
</section>
<section title="Process">
<t><list style="hanging">
<t hangText="Area Director: "> This role is discussed in
<xref target="AD" />.</t>
<t hangText="Working Group Chair: "> This role is discussed
in <xref target="Chair" />.</t>
<t hangText="WG Facilitator: "> When meetings tend to
become distracted or divisive, it often is helpful to
assign the task of "process management" to one
participant. <xref target="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.</t>
<t hangText="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. </t>
<t hangText="Scribe: "> 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'. <xref
target="I-D-Jscribe" /></t>
</list></t>
</section>
</section>
<section title="WG External Administration">
<section anchor="Formation" title="Working group Formation">
<t>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. </t>
<t>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.</t>
<section anchor="FormCriteria" title="Criteria for formation">
<t>When determining whether it is appropriate to create a
working group, the Area Director(s) and the IESG will
consider several issues: <list style="hanging">
<t hangText="Issues: ">Are the issues that the working
group plans to address clear and relevant to the
Internet community? </t>
<t hangText="Goals: ">Are the goals specific and
reasonably achievable, and achievable within a
reasonable time frame? </t>
<t hangText="Risks/Urgency: ">What are the risks and
urgency of the work, to determine the level of effort
required? </t>
<t hangText="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. </t>
<t hangText="Interest: ">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.</t>
<t hangText="Expertise: ">Is there enough expertise
within the IETF in the working group's topic, and are
those people interested in contributing in the working
group? </t>
<t hangText="Market: ">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. </t>
<t hangText="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. </t>
<t hangText="IPR: ">Are all known intellectual property
rights relevant to the proposed working group's
efforts issues understood? </t>
<t hangText="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? </t>
<t hangText="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. </t>
<t hangText="SDO Overlap: ">Do the working group's goals
overlap with known work in another standards body, and
if so is adequate liaison in place?</t>
</list>
</t>
<t>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.</t>
</section>
<section anchor="BOF" title="Birds of a Feather (BOF)">
<t>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 (<xref target="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.</t>
<t> 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.</t>
<t>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.</t>
<t>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,
<list style="symbols">
<t>The Area Director MAY require the establishment of an
open email list prior to authorizing a BOF. This
permits initial exchanges and sharing of framework,
vocabulary and approaches, in order to make the time
spent in the BOF more productive. </t>
<t>The Area Director MAY require that there be a draft of
the WG charter prior to holding a BOF. </t>
<t>The Area Director MAY require that a BOF not be held
until an Internet-Draft describing the proposed
technology has been issued so it can be used as a
basis for discussion in the BOF.</t>
</list></t>
<t>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. </t>
<t>Usually the outcome of a BOF will be one of the following:
<list style="symbols">
<t>There was enough interest and focus in the subject to
warrant the formation of a WG</t>
<t>While there was a reasonable level of interest
expressed in the BOF some other criteria for working
group formation was not met, per <xref
target="FormCriteria" /></t>
<t>The discussion came to a fruitful conclusion, with
results to be written down and published, however
there is no need to establish a WG</t>
<t>There was not enough interest in the subject to
warrant the formation of a WG</t>
</list></t>
</section>
<section anchor="CharterDev" title="Charter Development">
<t>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 <xref
target="CharterContent" />. The development of the
proposed charter is overseen by a shepherding Area Director
and can be pursued in a number of ways.</t>
<t> 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.</t>
<t> 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.(<xref target="RFC5434" />,<xref
target="BOF" />) 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.</t>
<t> 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.</t>
</section>
<section title="Charter review & approval">
<t>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. <list style="hanging">
<t hangText="(Task) ">To facilitate working group
efforts, an Area Director MAY assign a Adviser from
among the ranks of IETF participants. (<xref
target="Roles" />)</t>
</list> At the discretion of the Area Director, approval of
a new WG MAY be withheld in the absence of sufficient
Adviser resources.</t>
<t>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:
<list style="numbers">
<t>In parallel:<list style="symbols">
<t>The charter is submitted for review by the
IAB</t>
<t>It is also submitted for approval by the
IESG.</t>
</list></t>
<t>After a review period of at least a week, in
parallel:<list style="symbols">
<t> the proposed charter is posted to the
IETF-announce mailing list as a public notice
that the formation of the working group is being
considered.</t>
<t> the proposed charter is also posted to the
"new-work" mailing list. This mailing list has
been created to let qualified representatives
from other standards organizations know about
pending IETF working groups.</t>
</list></t>
<t> 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</t>
</list></t>
<t>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.</t>
</section>
<section anchor="Milestones" title="Milestones Revision">
<t>The milestone list is expected to be updated periodically.
Updated milestones are (re-)negotiated with the Area
Director<!--
and the IESG-->, as
needed, and then are submitted to the IESG Secretariat: <figure>
<artwork align="center"><![CDATA[iesg-secretary@ietf.org]]></artwork>
</figure></t>
</section>
<section anchor="Rechartering"
title="Rechartering a Working Group">
<!--<t>Alternatively, with the concurrence
of the IESG, Area Director, the WG Chair, and the WG
participants, the objectives or assignment of the working group
MAY be extended by modifying the working group's charter
through a rechartering process. (<xref target="Recharter"
/>)</t>-->
<t>Charters MAY be renegotiated periodically to reflect the
current status, organization or goals of the working group. </t>
<t>Rechartering a working group follows the same procedures
that the initial chartering does <xref target="Formation"
/>. </t>
</section>
</section>
<section anchor="CharterContent" title="Charter Content">
<t>Charter development and approval, rechartering, and milestone
revision are discussed in <xref target="Formation" />.</t>
<t> Examples working group charters are shown in <xref
target="Sample-Charters" /></t>
<t>A charter consists of the following sections: <list
style="hanging">
<t hangText="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. </t>
<t hangText="Chair(s): "> 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.</t>
<t hangText="(Optional) Other Staff:">Optional positions,
such as secretary and technical adviser.</t>
<t hangText="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). </t>
<t hangText="Responsible Area: "> Director The Area
Director who acts as the primary IESG contact for the
working group.</t>
<t hangText="Mailing list: "> An IETF working group MUST
have a general Internet mailing list. The working group
charter MUST include: <list style="symbols">
<t>The address to which a participant sends a
subscription request and the procedures to follow
when subscribing, </t>
<t>The address to which a participant sends
submissions and special procedures, if any, and </t>
<t>The location of the mailing list archive. </t>
</list>For basic IETF requirements concerning mailing
list configuration and use. (<xref target="Lists" />)</t>
<t hangText="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.</t>
<!-- <list>
<t>((The IETF Secretariat has confirm that it no longer
circulates only the first paragraph by itself. So
that text no longer needs to function as a standalone
'abstract'? /Dave )) The first paragraph
is circulated independently, such as when
announcing the formation of the working group. It
MUST give a brief summary of the problem area,
basis, goals, deliverables and approach(es) planned
for the working group. Hence this paragraph can be
used as a standalone overview of the working
group's effort.</t>
</list> -->
<t>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:<list style="symbols">
<t>Architecture</t>
<t>Operations</t>
<t>Security</t>
<t>Network management</t>
<t>Scaling</t>
<t>Transition (where applicable)</t>
</list></t>
<t hangText="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. </t>
<t>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.</t>
<t>It is helpful to specify milestones for every 3-6 months,
so that progress can be gauged easily. </t>
</list>
</t>
</section>
<section title="Submission & Publication of Documents">
<t>Once a WG has determined that rough consensus exists within the
WG for the advancement of a document, the following MUST be
done: <list style="hanging">
<t hangText="(Task) "> The version of the relevant document
exactly as agreed to by the WG MUST be in the
Internet-Drafts directory, formatted according to <xref
target="RFC" />
</t>
<t hangText="(Task) ">The WG Chair MUST initiate a
publication request through the Datatracker entry for the
document</t>
</list> 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.</t>
<t hangText="(Task) ">Unless returned by the IESG to the WG for
further development, progressing of the document is then the
responsibility of the IESG. </t>
<t hangText="(Task) ">After IESG approval, responsibility for
final disposition is the joint responsibility of the RFC
Editor, the WG Chair and the Document Writer.</t>
<t hangText="(Task) ">The Chair and/or Document Editor will work
with the RFC Editor to ensure document conformance with RFC
publication requirements <xref target="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.</t>
</section>
<section anchor="Termination" title="Working Group Termination">
<t>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 <xref target="Termination" />.></t>
<t>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.</t>
<t>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: <list style="symbols">
<t>Recharter to refocus its tasks (See <xref
target="Rechartering" />)</t>
<t>Choose new Chair(s)</t>
<t>Disband</t>
</list></t>
<t>If the working group disagrees with the Area Director's choice,
it MAY appeal to the IESG. <xref target="Appeals" /></t>
</section>
<section anchor="Appeals" title="Contention and appeals">
<t>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.</t>
<t>Formal procedures for requesting a review of WG, Chair, Area
Director or IESG actions and conducting appeals are documented
in <xref target="RFC2026">The Internet Standards
Process</xref>. </t>
</section>
</section>
<section title="Security Considerations">
<t />
</section>
</middle>
<back>
<references title="References - Normative">
<!--[1] Bradner, S., Editor, "The Internet Standards Process ‐ Revision
3", BCP 9, RFC 2026, October 1996.-->
<reference anchor="RFC2026">
<front>
<title abbrev="Internet Standards Process">The Internet
Standards Process -- Revision 3</title>
<author fullname="Scott O. Bradner" initials="S."
surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address>
</author>
<date month="October" year="1996" />
<abstract>
<t>This memo documents the process used by the Internet
community for the standardization of protocols and
procedures. It defines the stages in the standardization
process, the requirements for moving a document between
stages and the types of documents used during this
process. It also addresses the intellectual property
rights and copyright issues associated with the standards
process.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9" />
<seriesInfo name="RFC" value="2026" />
<format octets="86731"
target="http://www.rfc-editor.org/rfc/rfc2026.txt" type="TXT"
/>
</reference>
<reference anchor="IETF-Meetings">
<front>
<title>IETF Meetings</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="http://www.ietf.org/meeting/" />
</reference>
<reference anchor="MeetMaterials">
<front>
<title>Meeting Materials</title>
<author />
<date />
</front>
<seriesInfo name="WEB"
value="http://www.ietf.org/wg/meeting-materials.html" />
</reference>
<reference anchor="MeetRequest">
<front>
<title>Requesting Meeting Sessions at IETF Meetings</title>
<author />
<date />
</front>
<seriesInfo name="WEB"
value="http://www.ietf.org/old/2009/instructions/MTG-SLOTS.html"
/>
</reference>
<reference anchor="MeetMaterialTool">
<front>
<title>The IETF Meeting Materials Management Tool</title>
<author />
<date />
</front>
<seriesInfo name="WEB"
value="http://www.ietf.org/old/2009/instructions/meeting_materials_tool.html"
/>
</reference>
<reference anchor="AgendaNotes">
<front>
<title>Formatting and Content of IETF Working Group Agendas and
Minutes</title>
<author />
<date />
</front>
<seriesInfo name="WEB"
value="http://www.ietf.org/wg/agenda-minutes-procedures.html"
/>
</reference>
<reference anchor="Interim">
<front>
<title>Interim Meetings</title>
<author />
<date />
</front>
<seriesInfo name="WEB"
value="http://www.ietf.org/meeting/interim-meetings.html" />
</reference>
</references>
<references title="References - Informative">
<reference anchor="Interim-Train">
<front>
<title>Routing Area Chair Training: Interim Meetings</title>
<author fullname="Alia Atlas" initials="A." surname="Atlas"> </author>
<author fullname="Benson Schliesser" initials="B."
surname="Schliesser"> </author>
<author fullname="Sean Turner" initials="S." surname="Turner"> </author>
<date day="21" month="January" year="2015" />
</front>
<seriesInfo name="WEB"
value="https://tools.ietf.org/area/rtg/trac/raw-attachment/wiki/WGChairTraining/rtgwg_train_4.pdf"
/>
</reference>
<reference anchor="RFC-Editor">
<front>
<title>RFC Editor</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="http://www.rfc-editor.org/" />
</reference>
<reference anchor="RFC-IETF">
<front>
<title>Request for Comments (RFC)</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="http://www.ietf.org/rfc.html" />
</reference>
<reference anchor="I-D">
<front>
<title>Internet-Drafts (I-Ds)</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="https://www.ietf.org/id-info/" />
</reference>
<reference anchor="AD-Desc">
<front>
<title>Area Director Qualifications</title>
<author />
<date />
</front>
<seriesInfo name="WEB"
value="http://trac.tools.ietf.org/group/iesg/trac/wiki/AreasDescription"
/>
</reference>
<reference anchor="I-D-Guidelines">
<front>
<title>Guidelines to Authors of Internet-Drafts</title>
<author fullname="R. Housley" initials="R." surname="Russ">
<organization>Vigil Security</organization>
</author>
<date day="7" month="December" year="2010" />
</front>
<seriesInfo name="WEB"
value="https://www.ietf.org/id-info/guidelines.html" />
</reference>
<reference anchor="RFC2418">
<front>
<title abbrev="IETF Guidelines">IETF Working Group Guidelines
and Procedures</title>
<author fullname="Scott Bradner" initials="S."
surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass Ave.</street>
<street>Cambridge</street>
<country>MA</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address>
</author>
<date month="September" year="1998" />
<area>General</area>
<keyword>Internet Engineering Task Force</keyword>
<abstract>
<t> The Internet Engineering Task Force (IETF) has
responsibility for developing and reviewing
specifications intended as Internet Standards. IETF
activities are organized into working groups (WGs). This
document describes the guidelines and procedures for
formation and operation of IETF working groups. It also
describes the formal relationship between IETF
participants WG and the Internet Engineering Steering
Group (IESG) and the basic duties of IETF participants,
including WG Chairs, WG participants, and IETF Area
Directors. </t>
</abstract>
</front>
<seriesInfo name="BCP" value="25" />
<seriesInfo name="RFC" value="2418" />
<format octets="62857"
target="http://www.rfc-editor.org/rfc/rfc2418.txt" type="TXT" />
<format octets="62422"
target="http://xml.resource.org/public/rfc/xml/rfc2418.xml"
type="XML" />
</reference>
<reference anchor="IETF">
<front>
<title>About the IETF</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="http://www.ietf.org/about/" />
</reference>
<reference anchor="Tao">
<front>
<title>The Tao of IETF: A Novice's Guide to the Internet
Engineering Task Force</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="http://www.ietf.org/tao.html" />
</reference>
<reference anchor="ChairGuide">
<front>
<title>WG Chairs' Guide,
http://wiki.tools.ietf.org/group/wgchairs/</title>
<author />
<date />
</front>
<seriesInfo name="WEB"
value="http://wiki.tools.ietf.org/group/wgchairs/" />
</reference>
<reference anchor="WG">
<front>
<title>Working Groups</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="http://www.ietf.org/wg/" />
</reference>
<reference anchor="Areas">
<front>
<title>Areas</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="https://www.ietf.org/iesg/area.html"
/>
</reference>
<reference anchor="RFC1603">
<front>
<title abbrev="IETF Working Group Guidelines">IETF Working
Group Guidelines and Procedures</title>
<author fullname="Erik Huizer" initials="E." surname="Huizer">
<organization>SURFnet bv</organization>
<address>
<postal>
<street>P.O. Box 19035</street>
<city>Utrecht</city>
<region />
<code>3501 DA</code>
<country>NL</country></postal>
<phone>+31 30 310290</phone>
<facsimile>+31 30 340903</facsimile>
<email>Erik.Huizer@SURFnet.nl</email></address>
</author>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Silicon Graphics, Inc.</organization>
<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<street>P.O. Box 7311</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country></postal>
<phone>+1 415 390 1804</phone>
<facsimile>+1 415 962 8404</facsimile>
<email>dcrocker@sgi.com</email></address>
</author>
<date month="March" year="1994" />
<abstract>
<t>The Internet Engineering Task Force (IETF) has
responsibility for developing and reviewing
specifications intended as Internet Standards. IETF
activities are organized into working groups (WGs). This
document describes the guidelines and procedures for
formation and operation of IETF working groups. It
describes the formal relationship between IETF
participants WG and the Internet Engineering Steering
Group (IESG). The basic duties of IETF participants,
including WG Chair and IESG Area Directors are
defined.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1603" />
<format octets="63900"
target="http://www.rfc-editor.org/rfc/rfc1603.txt" type="TXT"
/>
</reference>
<!--[2] Hovey, R., and S. Bradner, "The Organizations involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.-->
<reference anchor="RFC2028">
<front>
<title abbrev="IETF Organizations">The Organizations Involved
in the IETF Standards Process</title>
<author fullname="Richard Hovey" initials="R." surname="Hovey">
<organization>Digital Equipment Corporation</organization>
<address>
<postal>
<street>1401 H Street NW</street>
<street>Washington DC 20005</street></postal>
<phone>+1 202 383 5615</phone>
<email>hovey@wnpv01.enet.dec.com</email></address>
</author>
<author fullname="Scott Bradner" initials="S."
surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass Ave. Rm 813</street>
<street>Cambridge MA 02138</street></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address>
</author>
<date month="October" year="1996" />
<area>General</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>standards process</keyword>
<abstract>
<t> This document describes the individuals and
organizations involved in the IETF. This includes
descriptions of the IESG, the IETF Working Groups and the
relationship between the IETF and the Internet Society.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="11" />
<seriesInfo name="RFC" value="2028" />
<format octets="13865"
target="http://www.rfc-editor.org/rfc/rfc2028.txt" type="TXT" />
<format octets="17202"
target="http://xml.resource.org/public/rfc/xml/rfc2028.xml"
type="XML" />
</reference>
<!--<reference anchor="RFC2282">
<front>
<title abbrev="IAB and IESG Confirmation">IAB and IESG
Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees</title>
<author fullname="James M. Galvin" initials="J.M."
surname="Galvin">
<organization>eList eXpress LLC</organization>
<address>
<postal>
<street>PO Box 220</street>
<street>Glenwood</street>
<street>21738</street>
<country>MD</country></postal>
<email>galvin@elistx.com</email></address>
</author>
<date month="February" year="1998" />
<area>General</area>
<keyword>Internet Architecture Board</keyword>
<keyword>Internet Engineering Steering Group</keyword>
<abstract>
<t> The process by which the members of the IAB and IESG are
selected, confirmed, and recalled is specified. The
evolution of the process has relied principally on oral
tradition as a means by which the lessons learned could
be passed on to successive committees. This document is a
self-consistent, organized compilation of the process as
it is known today. </t>
</abstract>
</front>
<seriesInfo name="BCP" value="10" />
<seriesInfo name="RFC" value="2282" />
<format octets="29852"
target="http://www.rfc-editor.org/rfc/rfc2282.txt" type="TXT" />
<format octets="43012"
target="http://xml.resource.org/public/rfc/html/rfc2282.html"
type="HTML" />
<format octets="28679"
target="http://xml.resource.org/public/rfc/xml/rfc2282.xml"
type="XML" />
</reference>-->
<!--[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
RFC 1796, April 1995.-->
<reference anchor="RFC1796">
<front>
<title>Not All RFCs are Standards</title>
<author fullname="Christian Huitema" initials="C."
surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>
<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<region />
<code>F-06561</code>
<country>FR</country></postal>
<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email></address>
</author>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences
Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country></postal>
<phone>+1 310 822 1511</phone>
<email>Postel@ISI.EDU</email></address>
</author>
<author fullname="Steve Crocker" initials="S."
surname="Crocker">
<organization>CyberCash, Inc.</organization>
<address>
<postal>
<street>2086 Hunters Crest Way</street>
<city>Vienna</city>
<region>VA</region>
<code>22181</code>
<country>US</country></postal>
<phone>+1 703 620 1222</phone>
<email>crocker@cybercash.com</email></address>
</author>
<date month="April" year="1995" />
<abstract>
<t>This document discusses the relationship of the Request
for Comments (RFCs) notes to Internet Standards.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1796" />
<format octets="7049"
target="http://www.rfc-editor.org/rfc/rfc1796.txt" type="TXT"
/>
</reference>
<!--[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.-->
<reference anchor="RFC2223">
<front>
<title>Instructions to RFC Authors</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences
Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street></postal>
<phone>+1 310-822-1511</phone>
<facsimile>+1 310-823-6714</facsimile>
<email>Postel@ISI.EDU</email></address>
</author>
<author fullname="Joyce K. Reynolds" initials="J.K."
surname="Reynolds">
<organization>USC/Information Sciences
Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street></postal>
<phone>+1 310-822-1511</phone>
<facsimile>+1 310-823-6714</facsimile>
<email>jkrey@isi.edu</email></address>
</author>
<date month="October" year="1997" />
<area>General</area>
<keyword>RFC authors</keyword>
</front>
<seriesInfo name="RFC" value="2223" />
<format octets="37948"
target="http://www.rfc-editor.org/rfc/rfc2223.txt" type="TXT" />
<format octets="37561"
target="http://xml.resource.org/public/rfc/xml/rfc2223.xml"
type="XML" />
</reference>
<!--[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Level", BCP 14, RFC 2119, March 1997.-->
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to
Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S."
surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t> In many standards track documents several words are used
to signify the requirements in the specification. These
words are often capitalized. This document defines these
words as they should be interpreted in IETF documents.
Authors who follow these guidelines should incorporate
this phrase near the beginning of their document: <list>
<t> The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC
2119. </t>
</list></t>
<t> Note that the force of these words is modified by the
requirement level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17970"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC5434">
<front>
<title>Considerations for Having a Successful
Birds-of-a-Feather (BOF) Session</title>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization />
</author>
<date month="February" year="2009" />
<abstract>
<t>This document discusses tactics and strategy for hosting
a successful IETF Birds-of-a-Feather (BOF) session,
especially one oriented at the formation of an IETF
Working Group. It is based on the experiences of having
participated in numerous BOFs, both successful and
unsuccessful. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5434" />
<format octets="33887"
target="http://www.rfc-editor.org/rfc/rfc5434.txt" type="TXT"
/>
</reference>
<reference anchor="RFC7221">
<front>
<title>Handling of Internet-Drafts by IETF Working
Groups</title>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization />
</author>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>
<date month="April" year="2014" />
<abstract>
<t>The productive output of an IETF working group is
documents, as mandated by the working group's charter.
When a working group is ready to develop a particular
document, the most common mechanism is for it to "adopt"
an existing document as a starting point. The document
that a working group adopts and then develops further is
based on initial input at varying levels of maturity. An
initial working group draft might be a document already
in wide use, or it might be a blank sheet, wholly created
by the working group, or it might represent any level of
maturity in between. This document discusses how a
working group typically handles the formal documents that
it targets for publication.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7221" />
<format octets="31669"
target="http://www.rfc-editor.org/rfc/rfc7221.txt" type="TXT"
/>
</reference>
<reference anchor="RFC7227">
<front>
<title>Guidelines for Creating New DHCPv6 Options</title>
<author fullname="D. Hankins" initials="D." surname="Hankins">
<organization />
</author>
<author fullname="T. Mrugalski" initials="T."
surname="Mrugalski">
<organization />
</author>
<author fullname="M. Siodelski" initials="M."
surname="Siodelski">
<organization />
</author>
<author fullname="S. Jiang" initials="S." surname="Jiang">
<organization />
</author>
<author fullname="S. Krishnan" initials="S." surname="Krishnan">
<organization />
</author>
<date month="May" year="2014" />
<abstract>
<t>This document provides guidance to prospective DHCPv6
option developers to help them create option formats that
are easily adoptable by existing DHCPv6 software. It also
provides guidelines for expert reviewers to evaluate new
registrations. This document updates RFC 3315.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="187" />
<seriesInfo name="RFC" value="7227" />
<format octets="83694"
target="http://www.rfc-editor.org/rfc/rfc7227.txt" type="TXT"
/>
</reference>
<reference anchor="RFC7282">
<front>
<title>On Consensus and Humming in the IETF</title>
<author fullname="P. Resnick" initials="P." surname="Resnick">
<organization />
</author>
<date month="June" year="2014" />
<abstract>
<t>The IETF has had a long tradition of doing its technical
work through a consensus process, taking into account the
different views among IETF participants and coming to (at
least rough) consensus on technical matters. In
particular, the IETF is supposed not to be run by a
"majority rule" philosophy. This is why we engage in
rituals like "humming" instead of voting. However, more
and more of our actions are now indistinguishable from
voting, and quite often we are letting the majority win
the day without consideration of minority concerns. This
document explains some features of rough consensus, what
is not rough consensus, how we have gotten away from it,
how we might think about it differently, and the things
we can do in order to really achieve rough
consensus.</t><t> Note: This document is quite
consciously being put forward as Informational. It does
not propose to change any IETF processes and is therefore
not a BCP. It is simply a collection of principles,
hopefully around which the IETF can come to (at least
rough) consensus.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7282" />
<format octets="52339"
target="http://www.rfc-editor.org/rfc/rfc7282.txt" type="TXT"
/>
</reference>
<reference anchor="RFC7322">
<front>
<title>RFC Style Guide</title>
<author fullname="H. Flanagan" initials="H." surname="Flanagan">
<organization />
</author>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>
<date month="September" year="2014" />
<abstract>
<t>This document describes the fundamental and unique style
conventions and editorial policies currently in use for
the RFC Series. It captures the RFC Editor's basic
requirements and offers guidance regarding the style and
structure of an RFC. Additional guidance is captured on a
website that reflects the experimental nature of that
guidance and prepares it for future inclusion in the RFC
Style Guide. This document obsoletes RFC 2223,
"Instructions to RFC Authors".</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7322" />
<format octets="49915"
target="http://www.rfc-editor.org/rfc/rfc7322.txt" type="TXT"
/>
</reference>
<reference anchor="Secretaries">
<front>
<title>IETF Working Groups' Secretaries</title>
<author fullname="M. Vigoureux" initials="M."
surname="Vigoureux">
<organization>Alcatel-Lucent</organization>
</author>
<author fullname="D. King" initials="D." surname="King">
<organization>Old Dog Consulting></organization>
</author>
<date day="11" month="November" year="2014" />
</front>
<seriesInfo name="I-D" value="draft-secretaries-good-practices" />
</reference>
<reference anchor="Facilitate">
<front>
<title>Facilitation</title>
<author />
<date />
</front>
<seriesInfo name="WEB"
value="http://en.wikipedia.org/wiki/Facilitation_%28business%29" />
</reference>
<reference anchor="I-D-Jscribe">
<front>
<title>The Jabber Scribe Role at IETF Meetings</title>
<author />
<date />
</front>
<seriesInfo name="I-D" value="draft-saintandre-jabber-scribe" />
</reference>
<reference anchor="MailList">
<front>
<title>Email Lists</title>
<author />
<date />
</front>
<seriesInfo name="WEB" value="http://www.ietf.org/list/" />
</reference>
</references>
<section title="Acknowledgements">
<t>The original version of this document was developed by Erik Huizer
and Dave Crocker. (<xref target="RFC1603" />) A revised version
was edited by Scott Bradner and reviewed by the Poisson Working
Group. (<xref target="RFC2418" />) The current version was
prompted by <xref target="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.</t>
<t>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.</t>
</section>
<section anchor="Sample-Charters" title="Sample Working Group Charters">
<t><list style="hanging">
<t hangText="NOTE: ">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</t>
</list></t>
<section title="DPRIVE">
<t><figure>
<artwork><![CDATA[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]]></artwork>
</figure></t>
</section>
<section title="iptel">
<t><figure>
<artwork><![CDATA[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
]]></artwork>
</figure></t>
</section>
<section title="rtg">
<t><figure>
<artwork><![CDATA[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]]></artwork>
</figure></t>
</section>
<section title="another one">
<figure>
<artwork />
</figure>
</section>
</section>
<section anchor="WG-Advice" title="[PROTO-WIKI] Working Group Advice">
<t><list style="hanging">
<t hangText="NOTE TO RFC EDITOR: ">Prior to publication, this
section is to be moved to an IETF wiki page, for on-going
enhancement.</t>
<t> ALSO: The document's reference to this section needs to be
modified to refer to that wiki.</t>
</list></t>
<t />
<section title="If you have a formal WG role...">
<t>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:<list style="symbols">
<t> Re-read <xref target="Tao">"The Tao of IETF: A Novice's
Guide to the Internet Engineering Task Force"</xref>.
You've already read it at least once, right? </t>
<t>Read <xref target="RFC7282" />. No, really, I know you
say you've read it; go read it again. Be sure you know
what "rough consensus" is, how it can be identified and
how it is used in the IETF. Pay particular attention to
its extended discussion of the handling of 'minority'
views.</t>
</list></t>
</section>
<section title="Advice for Chairs">
<t>
<list style="symbols">
<t>Become familiar with: <xref target="ChairGuide" /></t>
<t>Some WGs do work that requires interaction and
cooperation with other standards bodies. WG
administrative staff should be aware of the possibility
of such interactions, as formally described regarding
IEEE in RFC 7241 and ITU-T in RFC 6756. The IETF has
established a formal liaison role for some of these
interactions, as defined in RFC 4691. RFC 4929 describes
a specific (and historically interesting) example of
interaction between the IETF and ITU-T.</t>
<t> Handling Internet-Drafts as part of the activities of
Working Groups is summarized in RFC 2418bis and described
in detail in RFC 7241. The states that a WG document can
take are defined in RFC 6174.</t>
<t> The co-chairs are responsible for behavior of WG
participants as part of the IETF. RFC 7154 can help to
identify and deal with unacceptable behavior.</t>
<t> Intellectual property rights (IPR) management is crucial
to the IETF and has been the source of serious legal
issues in the past. Read RFC 6702 to understand the IETF
disclosure rules and how to make sure your WG stays in
compliance with those rules. Also read RFC 6701 to learn
how you can deal with IPR policy violations.</t>
</list></t>
</section>
<section title="Meetings">
<section title="WG meeting preparation">
<section title="Request meeting slot(s)">
<t>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.</t>
<t>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.</t>
</section>
<section title="Create and post agenda">
<t> Well before the meeting, the WG administration posts a
request for proposed discussion items, presentations and
other agenda items to the WG mailing list.</t>
<t>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.</t>
</section>
<section title="Post meeting materials">
<t>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.</t>
<t>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.</t>
</section>
<section title="Other meeting prep">
<t>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.</t>
</section>
</section>
<section title="WG meeting operation">
<t><list>
<t>* Confirm meeting room logistics: AV equipment,
presentation materials, etc.</t>
<t>* Pass around attendance records ("blue sheets")</t>
<t>* Bash the agenda</t>
<t>* WG status update</t>
<t>* Proceed through the agenda</t>
<t>* Record significant consensus calls, process actions,
technical decisions</t>
</list></t>
</section>
<section title="WG Meeting Followup">
<t><list>
<t>* Deliver a one paragraph summary of the meeting,
including significant consensus calls, process
actions, technical decisions, for the Area Director
before the end of the IETF meeting</t>
<t>* Prepare notes, using notes, jabber log and audio
recording of the meeting; once the notes are ready,
post the notes to the IETF Meeting Materials</t>
</list></t>
</section>
</section>
<section title="Ongoing WG operation">
<section title="Managing Individual Documents">
<t>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.</t>
<t>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.</t>
</section>
<section title="Charter Management">
<t><list>
<t>* The WG administration reviews and periodically
updates the WG milestones.</t>
</list></t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:49:54 |