Network Working Group H. Alvestrand
Internet-Draft Cisco Systems
Expires: July 7, 2003 January 6, 2003
An IESG charter
draft-iesg-procedures-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 7, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo describes the current operating procedures of the Internet
Engineering Steering Group (IESG), a management function of the
Internet Engineering Task Force (IETF).
This memo is not intended to become an RFC, but provides information
to the Internet community, for which the internet-drafts mechanism is
a convenient distribution veichle
Discussion of this memo is encouraged on the POISED mailing list
<poised@lists.tislab.com>
Alvestrand Expires July 7, 2003 [Page 1]
Internet-Draft An IESG charter January 2003
1. Introduction
This document gives some details of IESG procedure. It is intended
as a dynamically changeable document, and is intended to give
visibility to the current process, not to serve as a template for
what the process "ought" to be.
1.1 Notational conventions
The term "standards-track documents" is used to cover internet-drafts
that are being evaluated by the IESG for publication as Proposed
Standard, Draft Standard, Standard or Best Current Practice (BCP).
Not all documents evaluated for the standards track are published as
such.
The term "responsible AD" is used to indicate the Area Director that
is in charge of shepherding a document. For working group documents,
this will normally be the AD in charge of the working group; for non-
WG documents, it will be the AD that is in charge of the IETF
activity most closely associated with the subject matter of the
document.
At times, such as when the AD that would normally be selected is a
document author, or is adamantly opposed to the document, another AD
will take on that role.
All person roles described in this document may at times be filled by
persons of both sexes. The English language does not admit a short,
gender-neutral pronoun describing a person whose sex is not
determined by context. In the interest of political incorrectness,
this document will randomly refer to people as "he" or "she", without
regard to consistency or appropriateness.
Alvestrand Expires July 7, 2003 [Page 2]
Internet-Draft An IESG charter January 2003
2. IESG communications
The IESG is in constant session through its mailing list -
iesg@ietf.org. The IESG has a teleconference every second Thursday
for 2 1/2 hours, which is the place where decisions get reviewed and
initial IESG consensus is gauged.
Alvestrand Expires July 7, 2003 [Page 3]
Internet-Draft An IESG charter January 2003
3. IESG decision making
The IESG attempts to make all its decisions by consensus.
The normal behaviour expected of an AD is that he/she searches for
consensus, raises objections if he has them, listens to the arguments
for and against her objections, and makes an informed decision about
whether to go along with the consensus of the group, attempt to go
further in discussing the problem, or recusing himself from the
action because she has insoluble problems with the issue at hand.
The details of the search for consensus will differ according to the
form of action to be taken; see below.
Alvestrand Expires July 7, 2003 [Page 4]
Internet-Draft An IESG charter January 2003
4. IESG document review procedures
The IESG review procedure is defined by the IESG, within the limits
given by the rules (RFC 2026), the WG procedures (RFC xxx) and the
IESG Charter.
The procedure consists of:
o An initial review by the responsible AD, assisted by whatever
reviewers the AD wants to bring to bear. This may include an IETF
Last Call, and must include such a call for standards-track
documents.
o Once the responsible AD is satisfied that the document is worth
sponsoring, a review by the entire IESG
o If the IESG has questions or comments, the responsible AD takes
the token to resolve these with the authors or WG responsible
before taking the (possibly revised) document back to the IESG for
re-review.
The procedure of IESG evaluation is different for standards-track
documents and non-standards-track documents.
4.1 IESG review of standards-track documents
For this class of document, each AD is requested to state an opinion.
The responsible AD MUST register a "yes" vote to the document in
order to get it on the agenda. At least 2/3 of the ADs that are not
recusing themselves must register either "Yes" or "No Objection" in
order for the document to go out.
If an AD has an objection to the document (called a DISCUSS opinion),
this is discussed on the mailing list, and on a telechat. If the
IESG comes to consensus that the objection is worth sustaining, the
responsible AD is tasked with resolving the matter with the working
group or author. This may involve an explanation of the group's
choices, clarification of text in the document, or a reevaluation of
the choices made.
Normally, the AD contacts the WG chairs or document authors to
discuss the issue.
The IESG tries to get a "token holder" AD for the objection; the
chosen holder is not necessarily the one who raised the objection,
but one who the IESG trusts to detect whether the problem is solved
or not. When there are multiple, significantly different objections,
there are often multiple token holders.
Alvestrand Expires July 7, 2003 [Page 5]
Internet-Draft An IESG charter January 2003
When a document is updated, the responsible AD will notify the token
holding AD, and he will review the document; it can then either be
approved instantly (if the responsible AD and token-holding AD agree
that there are no further problems), or it can be put on the agenda
for a new telechat.
The IESG tries to get all objections to a document in a single pass;
however, this does not always succeed, and at times, resolving some
issues can cause other problems to surface. When the working group
or author takes so long to revise a document that ADs have been
replaced before the document comes back for re-review, the new eyes
will often see new problems with the document.
4.2 IESG review of WG non-standards-track RFCs
For this class of document, there is no requirement that all ADs give
an opinion on the document. The call is instead "does anyone have
any objection to this going forward"; if there is none, the document
is approved.
An objection to a document is handled much like that for standards-
track documents; the shepherding AD takes the issue to the author or
WG for discussion and clarification.
4.3 IESG review of non-WG, non-standards-track documents
These documents are referred to the IESG by the RFC Editor. The IESG
review is supposed to uncover:
o Whether the document should be reviewed by a currently active IETF
working group
o Whether the document is an attempt to end-run the IETF standards
process
o Whether the document is misrepresenting the IETF community view or
otherwise is actively harmful to the IETF community
As with all documents, a shepherding AD is assigned, and she is
responsible for reading the document and deciding whether more review
outside the IESG is required before going forward.
In some cases, such as when a document describes IANA considerations
that require "IETF consensus", the AD may ask for an IETF-wide Last
Call on the document, in order to notify the community that the
document is being processed.
The basic question of whether the document is worth publishing is
Alvestrand Expires July 7, 2003 [Page 6]
Internet-Draft An IESG charter January 2003
left to the RFC Editor; the IESG will only recommend for or against
publication. In some cases, the IESG will ask for a change in the
title of a document (for instance to insert the name of the
protocol's owner into the title of a document describing a
proprietary protocol), or ask for an "IESG Note" clarifying some
issue (often the relationship of the document to the IETF process) on
the front page of the document.
4.4 IESG review considerations
The level of review performed by the IESG varies according to the
IESG's evaluation of the importance and quality of the document and
the process that produced it.
An uncontroversial or unimportant document from a well-behaved
working group is likely to get a light reading once the responsible
AD signs off on it; ADs are likely to assume that it is OK, and only
check quickly that they don't see anything obviously broken in their
particular area of expertise (such as missing security sections or
other nits).
Documents that are regarded as important, or have been controversial,
are likely to receive more review; the IESG wishes to reassure itself
that the controversial issues are indeed settled, and not just
papered over; in the process, the ADs are likely to find more
"trivial" problems than they would otherwise do, too.
Alvestrand Expires July 7, 2003 [Page 7]
Internet-Draft An IESG charter January 2003
5. IESG working group management
5.1 Working group creation
A working group proposal is always worked out between a responsible
AD and the working group proposers.
When the responsible AD thinks that a working group charter is a good
idea, she may send an informal note to the IESG and IAB mailing list
to get initial feedback; this is often called the "laugh test".
When the AD thinks that the working group description is ready for
wider review, the AD sends it to the IESG secretary in order to place
it on a telechat agenda; the IESG secretary will then send the
document to the IESG and IAB mailing lists for initial review, with
copy to the proposed WG chairs.
If no IESG member objects to the charter, the IESG secretary then
sends the proposed charter to the IETF-announce list and to the new-
work list (which is a list maintained for cooperation between
standards bodies). The purpose of this posting is to make sure IETF
members and other SDOs are notified of the impending WG creation, and
have a chance to raise objections if they want to.
The charter is placed on the next telechat agenda 2 weeks later, and
if no IESG member objects at that time, the charter of the new
working group is approved.
5.2 Working group modification
When a working group charter is changed, the procedure depends on the
type of change.
o Changes to milestone dates are handled by the chairs notifying the
IESG secretariat (at ietf-action@ietf.org) and the AD, and the AD
approving them.
o Changes to milestone text are handled by the chairs and the AD
working out new text, the chairs sending the updates to the IESG
secretary, and the AD approving them.
o Adding, removing and replacing chairs is handled by the AD, who
notifies the IESG secretary, who updates the charter.
o Changes to the body of a charter requires IESG approval.
When updating the body of a charter, the new charter is sent to the
IESG secretary, who places it on the IESG telechat agenda; if no IESG
Alvestrand Expires July 7, 2003 [Page 8]
Internet-Draft An IESG charter January 2003
member objects, the charter is approved. The IESG has the option of
sending the revised charter to ietf-announce and new-work for public
review, and will always do so if substantial new work items are added
to the task list of the WG.
When the changed charter is approved, the updated charter is always
sent to ietf-announce.
5.3 Working group termination
A working group is terminated when the responsible AD decides that
the working group needs to be terminated. This may have multiple
causes:
o The working group is finished with its work, and its RFCs are
published (success)
o The AD concludes that letting the working group continue its work
does not contribute to the IETF's forward progress (failure)
A failed working group may be considered failed because the work is
being done by other groups in the IETF, because the solutions being
worked on are no longer considered relevant to the IETF, or because
the group is, in the opinion of the AD, not making forward progress
on achieving its goals.
In both cases, the working group may have internet-drafts assigned to
it that are not published as RFCs; these are then formally
reclassified as individual submissions, and the next update of these
documents is required to be named draft-<author>, not draft-ietf-
<wgname>.
The closing of a WG has no effect on the status of documents that
have already been approved by the IESG for publication.
Alvestrand Expires July 7, 2003 [Page 9]
Internet-Draft An IESG charter January 2003
6. IESG BOF procedures
Each AD decides which BOFs are appropriate in his area.
It is regarded as courteous, but not required, to pass the BOF
description to the IESG and IAB lists for feedback (and detection of
AD-shopping or end-runs) before approving the BOF.
Important things to consider when approving a BOF where the desired
outcome is formation of a WG include:
Whether or not there is a clearly defined problem statement
Whether or not there is a likely successful outcome
Whether or not there is sufficient community interest
The first two points are most easily answered by having (personal)
internet-drafts published before the BOF describing the work to be
done, or proposed solutions to it; the last point is most easily
demonstrated by having an active, open mailing list for the issue at
hand.
Alvestrand Expires July 7, 2003 [Page 10]
Internet-Draft An IESG charter January 2003
7. IESG appeals procedure
The formal appeals procedure is described in RFC 2026 section 6.5.
An appeal to the IESG is initiated by email to the IETF Chair, copied
to the IESG secretary. If the appeal is not clear about whether or
not it is an appeal, what is being appealed, or what the proposed
remedies are, there may be a dialogue between the chair and the
appealing person(s) to clarify the appeal.
The IESG will then ask the responsible AD to give her opinion of the
matter, as evidenced by the previous required step of discussing the
matter with the responsible AD.
The IESG will then discuss the matter in a telechat without the IAB
liaison or the IAB chair being present (in order to keep the
separation from the responsible body for a possible appeal), and will
usually assign to some AD (not the responsible AD) the task of
writing a draft response.
When the proposed response text is ready, the IESG will discuss it by
email (using a special mailing list that contains only the IESG
members), and in a new telechat where the IAB has been asked to
leave. When the IESG agrees upon the text, it is sent to the
appealant and to the ietf-announce list, as well as being archived on
the IESG's public web pages.
Author's Address
Harald Tveit Alvestrand
Cisco Systems
Weidemanns vei 27
Trondheim 7043
NO
EMail: harald@alvestrand.no
Alvestrand Expires July 7, 2003 [Page 11]
Internet-Draft An IESG charter January 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Alvestrand Expires July 7, 2003 [Page 12]
