[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: October 8, 2003                                   April 9, 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 October 8, 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

   Discussion of this memo is encouraged on the POISED mailing list

   STATUS NOTE (to be removed from RFC):
   This document is intended for publication as an Informational

Alvestrand              Expires October 8, 2003                 [Page 1]

Internet-Draft              An IESG charter                   April 2003

   document, detailing the instructions to the IESG that the IESG thinks
   it has been operating under.  It does not claim to represent
   consensus of the IETF that this is the right set of instructions to
   the IESG.  At this time (spring 2003), the structure of the IETF is
   undergoing reevaluation, and the result is likely to include changes
   to the IESG's role; spending time to get IETF consensus that this
   document represents the IETF consensus on what the IESG should do,
   which a BCP publication would indicate, seems like a less than useful

Alvestrand              Expires October 8, 2003                 [Page 2]

Internet-Draft              An IESG charter                   April 2003

1. Introduction

1.1 The role of the IESG

   The Internet Engineering Steering Group (IESG) is the group that
   exists to perform the overarching operational and technical
   management functions of the Internet Engineeering Task Force (IETF).

   As part of this function, the IESG is tasked with making the
   management decisions about working groups in the IETF, and with the
   final review and approval of documents produced by Working Groups and
   documents published as IETF standards-track documents, and review of
   other candidates for RFC publication.

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, Working Group
   Guidelines, which was later updated by RFC 2418 [2].

   As the community has grown, and the IESG has gathered experience, the
   ways in which the IESG has approeched its tasks have 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 elsewhere - consult the IESG's Web pages on the
   IETF Website for more information.

Alvestrand              Expires October 8, 2003                 [Page 3]

Internet-Draft              An IESG charter                   April 2003

2. The composition of the IESG

   The IESG has the following members:

   o  The IETF Chair, who may also function as an Area Director when

   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 IETF Chair and the Area Directors are selected by the IETF NomCom
   according to the procedures of BCP 10 [3] (Nomcom procedures).

   The IETF Executive Director is appointed by the IETF Chair, and is
   charged with running the IETF Secretariat; traditionally, this
   position has been held by a person employed full-time by the
   organization performing the secretariat function.

   The Liaison positions exist to facilitate the work of the IETF by
   expediting communication with other entities involved in the IETF
   process; which positions to have is decided by the IESG.

   The liaisons are selected as appropriate by the bodies they
   represent.  At the time of this writing, the liaisons present
   represent the following bodies:

      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
   Directors.  All IESG members can participate in the IESG's

Alvestrand              Expires October 8, 2003                 [Page 4]

Internet-Draft              An IESG charter                   April 2003

3. 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.

3.1 Decision making

   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
   two thirds of the members concur and there are no more than two

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

   The IESG may decide that other procedures for reaching a decision are
   apporpriate under specific conditions.  Such other procedures may

   o  Assertions of IETF consensus, such as when evaluating a standards
      action.  Here, in addition to the technical quality of the
      specification, the IESG has to evaluate the community opinion
      about the specification's subject matter; this has to happen with
      due notice and opportunity for community feedback.

   o  IESG actions in areas where the IESG has the authority to take
      action.  This does not need special rules.

   o  AD actions taken with the advice and consent of the IESG; the IESG
      is expected to be kept informed, and gives comment, but the
      authority to act is delegated to the AD.

   o  AD action; cases where an AD can take independent action without
      the need to consult the IESG first.

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

3.2 Openness and confidentiality

   The IESG publishes the record of decisions from all its meetings on
   the Internet, and conducts an open meeting at every IETF meeting.  It
   publishes all its final decisions as RFCs, Internet Drafts or
   messages to the IETF-announce mailing list, with copies kept on the
   IETF website where appropriate.

Alvestrand              Expires October 8, 2003                 [Page 5]

Internet-Draft              An IESG charter                   April 2003

   The IESG also discusses its business privately as a group, using any
   means of its choice, including email.  Records of those discussions
   are not required to be made public.  This is believed to be vital in
   permitting a frank exchange of viewpoints and worries, allowing
   people to speak out freely on topics known to be controversial, and
   permitting people to change their minds based on presented arguments.
   Decisions and their justification are a matter of public record.

   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 whose presence is seen as
   inappropriate for the particular discussion from such discussions.

   The chair may also apply exclusion to full members who have a serious
   conflict of interest on an issue.  Members can also choose to recuse
   themselves from discussion of an issue, or refrain from casting a
   vote on an issue, if they feel that is appropriate.

Alvestrand              Expires October 8, 2003                 [Page 6]

Internet-Draft              An IESG charter                   April 2003

4. The IESG role in working group management

   The IESG is in charge of managing the working group process.  While
   the process of running a working group is delegated to the working
   group chairs, the IESG is in charge of those processes that are
   beyond the scope of the working group chair's role.  Most of these
   functions are delegated by the IESG to a single Area Director - the
   "responsible Area Director" for the group.

4.1 Working group creation

   The formation of working groups is described in  BCP 25 [2] section
   2; this document does not repeat the text there, but gives some more
   details of IESG actions.

   A WG may be requested by members of the IETF community, who addresse
   the request to an AD that the requesters feel is the appropriate AD
   for the task, or the formation can be initiated by an AD.  The IESG
   may assign the prospective working group to another AD if the IESG
   thinks that is best.

   The AD is responsible for ensuring that a working group being
   chartered fulfils the criteria for WG formation given in BCP 25.  The
   charter is the result of a negotiation between the AD and the
   community of interest, with review and advice by the rest of the IESG
   and the IAB.

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

   All charters for proposed working groups are announced to the
   community at large when the IESG thinks that the charter is ready for
   review, but before the IESG makes a final decision on chartering the
   WG.  The final decision to charter a WG is an IESG decision.

   The BOF procedure described in BCP 25 [2] section 2.4 also requires
   approval from the relevant AD (the one who got the request or the AD
   that the IESG thinks is the right AD to manage the task).  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.

4.2 Working group management

   The role of the Area Director in WG management is described in BCP 25
   [2] 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 are coordinated with the

Alvestrand              Expires October 8, 2003                 [Page 7]

Internet-Draft              An IESG charter                   April 2003

   rest of the IETF.  The ADs help each other with maintaining cross-
   area coordination.

   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
   WG to work on it, or initiate creation of another WG.

   Substantive changes to the body of a WG's charter require the
   approval of the IESG.

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

4.3 Working group termination

   Terminating a WG is a decision of the responsible AD.

   A working group may be shut down when its work is completed, or when
   the AD concludes that letting the working group continue its work
   does not contribute to the IETF's forward progress.

   The decision to terminate a working group must be announced, and the
   reasons should be clearly given.

Alvestrand              Expires October 8, 2003                 [Page 8]

Internet-Draft              An IESG charter                   April 2003

5. The IESG role in document review

   The IESG is expected to ensure that the documents are of a sufficient
   quality for release as RFCs, that they describe their subject matter
   well, and that there are no outstanding engineering issues that
   should be addressed before publication.  The degree of review will
   vary with the intended status and perceived importance of the

   When there are problems or solutions that occur frequently, the IESG
   may publish documents describing the problems and how to avoid them,
   such as "IANA considerations" (BCP 26 [8]), or publish web pages with
   commonly used guidelines.

   Rules - stuff that the community is expected to follow - are decided
   by IETF consensus processing and commonly published as BCP RFCs.

   Guidance to the community that is of a more ephemeral and less
   normative nature is decided by the IESG and published on the IESG's
   Web pages.

5.1 Working group documents

   This role is described in BCP 25 [2] section 7.5 and 8, and BCP 9 [1]
   section 6.  The IESG role is one of review and approval.

5.2 Non-working group documents

5.2.1 Standards-track documents

   This role is described in BCP 9 [1] section 6.  Such documents are
   submitted to the IESG, which will assign them to a relevant AD.  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 will either approve or disapprove of the publication of the
   document on the standards track; no document can be published on the
   standards track without IESG approval.

   The IESG may decide that a document submitted for standards-track
   publication should instead be published as Experimental or

Alvestrand              Expires October 8, 2003                 [Page 9]

Internet-Draft              An IESG charter                   April 2003

   Informational, or that a document submitted for Proposed standard
   should be published as BCP, or vice versa.

5.2.2 Informational and Experimental documents

   These documents are normally submitted to the RFC Editor in
   accordance with the procedures of BCP 9 [1] section 4.2.3 and BCP 25
   [2] 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 BCP 9 [1]
   procedure, and documented in BCP 25 [2] section 8.

   The IESG may recommend that the document be published as-is, that it
   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

   If the document is referred to a WG, the WG can recommend that the
   document be adopted as a WG document, that it be published (possibly
   with comments), or that the IESG recommend to the RFC Editor that it
   not be published.  The responsible AD for the WG is responsible for
   getting a response from the WG in a timely manner.

   NOTE IN DRAFT: The following text tries to capture the occasional
   practice of processing individual documents through the IESG without
   first going through the RFC Editor.  It is not clear that the
   description is accurate, so this may change.  The IESG is discussing.

   When an AD decides that an Informational or Experimental document is
   of particular importance to the community, the AD may also choose to
   put it directly before the IESG.  This document will then be
   processed in the same fashion as an Informational or Experimental
   document from a working group.

5.3 IESG review procedures

   The IESG review procedure is defined by the IESG.

   For all documents, the IESG assigns a specific AD the responsibility
   for the document; that AD will normally review the document, and
   possibly ask for revisions to it to address obvious problems, before
   asking the entire IESG to consider it.

   The IESG has web pages as part of the IETF web (www.ietf.org);
   current details of procedures, as well as the means of finding the
   responsible AD for any document, are published there.

Alvestrand              Expires October 8, 2003                [Page 10]

Internet-Draft              An IESG charter                   April 2003

6. 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.  (BCP 25 [2] section
   1).  The area structure is defined by the IESG, and the IESG can add
   areas, redefine areas, merge areas or close down areas.

   Changes to the area structure affect the IETF in many ways; decisions
   to change the area structure are taken in consultation with the

   When changing the area structure, the IESG can decide which ADs are
   responsible for new and changed areas, including making one sitting
   AD responsible for multiple areas, 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 AD may be advised by one or more
   directorates, which are selected and chaired by the AD (BCP 25 [2]
   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 jointly 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

   The IESG decides which areas working groups belong to.

Alvestrand              Expires October 8, 2003                [Page 11]

Internet-Draft              An IESG charter                   April 2003

7. Other IESG roles

7.1 Staff supervision

   The IETF Chair has primary responsibility for supervising the work of
   the IETF Executive Director and the IETF Secretariat, with the advice
   and consent of the IESG, the IAB Chair and the ISOC president.

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

7.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 to the process when required, as
   well as addressing obvious miscarriages of process even when they do
   not fall into the categories described above.

7.3 External relations

   The 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 IAB may
   decide that the same function may also be done by others when it
   decides that this is more appropriate.

7.4 Appeals actions

   The formal appeals procedure is described in BCP 9 [1] section 6.5.

   Most decisions by a working group chair can be appealed to the AD,
   and decisions by an individual AD can be appealed to the IESG.

   Decisions of the IESG can be appealed to the IAB.

Alvestrand              Expires October 8, 2003                [Page 12]

Internet-Draft              An IESG charter                   April 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 October 8, 2003                [Page 13]

Internet-Draft              An IESG charter                   April 2003

9. Acknowledgements

   This work has been supported, aided and abetted by the whole IESG of
   the time of writing, and has benefitted from many other comments.

   Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret
   Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen and all others
   who provided comments on various versions of this document!

Alvestrand              Expires October 8, 2003                [Page 14]

Internet-Draft              An IESG charter                   April 2003

Normative references

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

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

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

Alvestrand              Expires October 8, 2003                [Page 15]

Internet-Draft              An IESG charter                   April 2003

Informative references

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

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

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

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

   [8]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Author's Address

   Harald Tveit Alvestrand
   Cisco Systems
   Weidemanns vei 27
   Trondheim  7043

   EMail: harald@alvestrand.no

Alvestrand              Expires October 8, 2003                [Page 16]

Internet-Draft              An IESG charter                   April 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 October 8, 2003                [Page 17]

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