[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thoughts over the holidays - IESG procedures.
wrote the enclosed just before Christmas and today.
lots of things not covered.
look at the intro for thoughts about how to publish and so on.
feedback @ multiple levels wanted:
- publish something-like-this: good/bad/pointless?
- if good: material covered: subjects to add/delete?
- proposals for changes to better describe our current procedures?
next thing on my todo list: making the proposed MoU into an I-D.....
Harald
Network Working Group H. Alvestrand
Internet-Draft Cisco Systems
Expires: June 1, 2003 December 2002
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 June 1, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). 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 June 1, 2003 [Page 1]
Internet-Draft An IESG charter December 2002
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
Alvestrand Expires June 1, 2003 [Page 2]
Internet-Draft An IESG charter December 2002
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
consensus on IESG action is gauged.
Alvestrand Expires June 1, 2003 [Page 3]
Internet-Draft An IESG charter December 2002
3. IESG decisionmaking
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.
Alvestrand Expires June 1, 2003 [Page 4]
Internet-Draft An IESG charter December 2002
4. IESG document review procedures
The IESG review procedure is defined by the IESG.
The procedure consists of:
o An initial review by the responsible AD, assisted by whatever
reviewers the AD wants to bring to bear
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 and BCP
For this class of document, each AD is requested to state an opinion.
One AD for the area to which the document belongs (the "shepherding
AD") MUST register a "yes" vote to the document in order to get it on
the agenda. At least 2/3 of the IESG must register either "Yes" or
"No Objection" in order for the document to go out.
If an AD has an objection to the document, this is discussed on the
mailing list, and on a telechat. If the IESG comes to consensus that
the objection is worth sustaining, the shepherding AD is tasked with
resolving the matter with the working group. This may involve an
explanation of the group's choices, clarification of text in the
document, or a reevaluation of the choices made.
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 a document is updated, the shepherding AD will notify the token
holding AD, and he will review the document; it can then either be
approved instantly (if the shepherding 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
Alvestrand Expires June 1, 2003 [Page 5]
Internet-Draft An IESG charter December 2002
issues can cause other problems to surface. When the working group
takes so long to revise a document that ADs have been replaced before
the document comes back for re-review, it is also hard to hold new
ADs to a promise to go lightly on surfacing remaining issues.
4.2 IESG review of 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.
Alvestrand Expires June 1, 2003 [Page 6]
Internet-Draft An IESG charter December 2002
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 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.
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 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 secretary 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
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, but does not need to do so.
When the changed charter is approved, the updated charter is always
Alvestrand Expires June 1, 2003 [Page 7]
Internet-Draft An IESG charter December 2002
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 June 1, 2003 [Page 8]
Internet-Draft An IESG charter December 2002
6. 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 response.
When the proposed response text is ready, the IESG will discuss it by
email and in a new telechat without the IAB. 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 June 1, 2003 [Page 9]
Internet-Draft An IESG charter December 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 June 1, 2003 [Page 10]