[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 3710

Network Working Group                                      H. Alvestrand
Internet-Draft                                             Cisco Systems
Expires: July 7, 2003                                    January 6, 2003

                            An IESG charter

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-

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 7, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


   This memo gives a charter for the Internet Engineering Steering Group
   (IESG), a management function of the Internet Engineering Task Force

   It is meant to document the charter of the IESG as presently
   understood (Jan 2003).

   Discussion of this memo is encouraged on the POISED mailing list

Alvestrand                Expires July 7, 2003                  [Page 1]

Internet-Draft              An IESG charter                 January 2003

1. Introduction

1.1 The role of the IESG

   The Internet Engineering Steering Group (IESG) is the operational and
   technical management function of the Internet Engineeering Task Force

   It is tasked with making the management decisions about working
   groups in the IETF, and with the final review and approval of
   documents published as IETF standards-track documents.

1.2 Historic note

   The role of the IESG in the IETF management structure has been
   largely constant since 1992, when the structure of the Internet
   standards process was defined by RFC 1310 (which was later updated by
   RFC 1602, RFC 1871 and RFC 2026).

   Some of the functions were also defined in RFC 1603 (which was later
   updated by RFC 2418).

   As the community has grown, and the IESG has gathered experience, the
   way in which the IESG approaches its tasks has varied considerably,
   but the tasks have remained relatively constant.

   This document describes the tasks assigned to the IESG.  It does not
   attempt to describe the procedures the IESG uses to accomplish these
   tasks; that is done in other memos.

Alvestrand                Expires July 7, 2003                  [Page 2]

Internet-Draft              An IESG charter                 January 2003

2. The composition of the IESG

   The IESG has the following members:

   o  The IETF Chair, who is also the General AD

   o  The Area Directors for the IETF Areas

   o  The IAB Chair and the IETF Executive Director, as ex-officio
      members of the IESG.

   o  Liaisons

   The Chair and the Area Directors are selected by the IETF NomCom
   according to the procedures of RFC 2282 (Nomcom procedures).

      The RFC Editor

      The IANA

      The IAB

   In addition, members of the IETF Secretariat are subscribed to the
   mailing list and present in the IESG meetings as needed in order to
   serve as a support function.

   Decisions of the IESG are made by the IETF Chair and the Area

Alvestrand                Expires July 7, 2003                  [Page 3]

Internet-Draft              An IESG charter                 January 2003

3. The IESG role in working group management

3.1 Working group creation

   The formation of working groups is described in RFC 2418 section 2.

   The normal case is that a working group is requested by members of
   the IETF community.

   Each area director is responsible for ensuring that a working group
   being chartered is relevant, has achievable goals and constitutes an
   acceptable risk, has sufficient interest and so on.  The charter is
   the result of a negotiation between the AD and the prospective
   chairs, with review by the IAB and approval by the IESG.  Normally,
   there will be communication with the community of interest for the
   working group too.

   The AD is also responsible for selecting chairs for the working group
   that he thinks will be up to the task.

   All charters for proposed working groups are announced to the
   community at large before the IESG makes a decision.

   The BOF procedure described in RFC 2418 section 2.4 also requires
   approval from the relevant AD.  A BOF is not required to start a
   working group, and a BOF may be held without the purpose being to
   create a working group.  BOFs are also often discussed with the IESG
   and IAB.

   If an AD determines that it is needed, the AD can initiate the
   formation of a working group.

3.2 Working group management

   The role of the Area Director in WG management is described in RFC
   2418 section 6.7.  The AD is responsible for making sure the working
   groups stay focused on the charter tasks, make forward progress, are
   coordinated with the rest of the area, and (with the IESG)
   coordinated with the rest of the IETF.

   In a well functioning working group, main responsibility for these
   things rests with the chairs; the AD will normally be able to
   concentrate on supporting the working group chairs' work.

   When a WG finds that it is essential that work gets done which is not
   on its charter, the AD, consulting with the rest of the IESG as
   required, is responsible for figuring out whether to add it to their
   charter, add it to another group's charter, task someone outside the

Alvestrand                Expires July 7, 2003                  [Page 4]

Internet-Draft              An IESG charter                 January 2003

   WG to work on it, or initiate creation of another WG.

   The Area Director is also responsible for picking and, when
   necessary, replacing working group chairs.  This is usually done in
   consultation with the IESG.

Alvestrand                Expires July 7, 2003                  [Page 5]

Internet-Draft              An IESG charter                 January 2003

4. The IESG role in document review

4.1 Working group documents

   This role is described in RFC 2418 section 7.5, and RFC 2026 section 
   6.  The IESG role is one of review and approval.

4.2 Non-working group documents

4.2.1 Standards-track

   This role is described in RFC 2026 section 6.  Such documents are
   submitted to the IESG, which will assign them to a relevant area
   director.  The IESG is responsible for determining:

   o  Whether or not the specification is appropriate for standards

   o  Whether or not the specification needs review by one or more
      existing WGs

   o  Whether or not the quality of the specification is adequate

   The IESG may recommend that a document submitted for standards-track
   publication instead be published as Experimental or Informational.

4.2.2 Informational and Experimental

   These documents are usually submitted to the RFC Editor in accordance
   with the procedures of RFC 2026 section 4.2.3 and RFC 2418 section 8.
   The IESG is asked to review all documents submitted in this fashion
   for conflicts with the IETF standards process or work done in the
   IETF community; this is a modification of the RFC 2026 procedure, and
   documented in RFC 2418 section 8.

   The IESG may recommend that the document be reviewed by a working
   group, that the document be published with an IESG note indicating
   issues such as conflict with the IETF standards process, or may
   recommend that the document not be published.

4.3 IESG review procedures

   The IESG review procedure is defined by the IESG.

   The IESG has web pages as part of the IETF web (www.ietf.org);
   current details of procedures should be published there.

Alvestrand                Expires July 7, 2003                  [Page 6]

Internet-Draft              An IESG charter                 January 2003

5. The IESG role in area management

   The IETF divides its work into a number of areas, each comprising
   working groups that relate to that area's focus.  (RFC 2418 section 
   1).  The area structure is defined by the IESG, and may be changed by
   the IESG.  The IESG decides which areas groups belong to.  When
   reassigning areas, the IESG can move responsibility for areas between
   IESG members, but the IESG can only add new members through the
   nomcom process.

   The primary task of area management is done by one or two area
   directors per area.  An area director may be advised by one or more
   directorates, which is selected and chaired by the area director (RFC
   2418 section 1).  Directorates may be specific to an area, specific
   to a technology, or chartered in some other fashion.

   The ADs for an area are responsible for making sure the WGs in the
   area are well coordinated, that there is coverage for the
   technologies needed in the area, and that the challenges that are
   most important to the Internet in that area are indeed being worked

   To that end, they may charter working groups, suggest modifications
   to working group charters, encourage people to work on specific work
   items within or outside working groups, or even shut down working
   groups that are not performing an useful function.

Alvestrand                Expires July 7, 2003                  [Page 7]

Internet-Draft              An IESG charter                 January 2003

6. Other IESG roles

6.1 Staff supervision

   The IESG is the main body responsible for supporting the IETF Chair
   in supervising the work of the IETF Secretariat.

   The supervision of the IANA and the RFC Editor is handled by the IAB.

6.2 Process management

   The IESG is responsible for making sure the IETF process is
   functional in all aspects.  This includes taking responsibility for
   initiating consideration of updates of the process when required, as
   well as addressing obvious miscarriages of process even when it does
   not fall into the categories described above.

6.3 External relations

   The main responsibility for handling external relations rests with
   the IAB, as described in the IAB Charter (RFC 2850).  However, when
   technical cooperation is required, it is essential that the work be
   coordinated with the relevant ADs.  This often means that ADs will
   function in a liaison role with other organizations, but the same
   function may also be done by others when that seems more appropriate.

Alvestrand                Expires July 7, 2003                  [Page 8]

Internet-Draft              An IESG charter                 January 2003

7. Procedural issues

   While the IESG is generally free to set its own procedures, some
   parts of the procedures are properly part of its charter.  These are
   given here.

7.1 Decision taking

   The IESG attempts to reach all decisions unanimously.  If unanimity
   cannot be achieved, the chair may conduct informal polls to determine
   consensus.  The IESG may make decisions and take action if at least
   seven members concur and there are no more than two dissents.

   For the purpose of judging consensus, only the IETF Chair and the
   Area Directors are counted.

   (NOTE: This rule is new, and has not been tried.  Its inclusion here
   is only done to get around the "how do we decide about a challenge to
   the rules" problem.)

   The IESG may reach decisions by face to face meeting, teleconference,
   Internet communication, or any combination of the above.

7.2 Openness and confidentiality

   The IESG publishes minutes of all its meetings on the Internet, and
   conducts an open meeting at every IETF meeting.  It publishes all its
   findings as RFCs, Internet Drafts or messages to the IETF-announce
   mailing list.  However, discussion of personnel matters and possibly
   legal and financial matters may sometimes be required to be kept
   confidential, and the chair may, with the consent of the full
   members, exclude liaison and ex officio members from such

Alvestrand                Expires July 7, 2003                  [Page 9]

Internet-Draft              An IESG charter                 January 2003

8. Security considerations

   The security of the Internet depends on standards giving proper
   thought to security.  Apart from that, there seem to be no
   considerations of security relevant to this memo.

Alvestrand                Expires July 7, 2003                 [Page 10]

Internet-Draft              An IESG charter                 January 2003


   [1]  Chapin, A., "The Internet Standards Process", RFC 1310, March

   [2]  Huitema, C. and P. Gross, "The Internet Standards Process --
        Revision 2", RFC 1602, March 1994.

   [3]  Huizer, E. and D. Crocker, "IETF Working Group Guidelines and
        Procedures", RFC 1603, March 1994.

   [4]  Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2,
        RFC 1871, November 1995.

   [5]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [6]  Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
        25, RFC 2418, September 1998.

   [7]  Galvin, J., "IAB and IESG Selection, Confirmation, and Recall
        Process: Operation of the Nominating and Recall Committees", BCP
        10, RFC 2282, February 1998.

Author's Address

   Harald Tveit Alvestrand
   Cisco Systems
   Weidemanns vei 27
   Trondheim  7043

   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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Alvestrand                Expires July 7, 2003                 [Page 12]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/