Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


Network Working Group H. Alvestrand Request for Comments: 3710 Cisco Systems Category: Informational February 2004

                          An IESG charter

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

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


 This memo provides a charter for the Internet Engineering Steering
 Group (IESG), a management function of the Internet Engineering Task
 Force (IETF).  It is meant to document the charter of the IESG as it
 is presently understood.

1. Introduction

1.1. The Role of the IESG

 The Internet Engineering Steering Group (IESG) is the group
 responsible for the direct operation of the IETF and for ensuring the
 quality of work produced by the IETF.
 The IESG charters and terminates working groups, selects their
 chairs, monitors their progress and coordinates efforts between them.
 The IESG performs technical review and approval of working group
 documents and candidates for the IETF standards track, and reviews
 other candidates for publication in the RFC series.  It also
 administers IETF logistics, including operation of the Internet-Draft
 document series and the IETF meeting event.

Alvestrand Informational [Page 1] RFC 3710 An IESG Charter February 2004

1.2. Historic Note

 The role of the IESG in the IETF management structure has been
 largely constant since 1993, after the significant changes introduced
 by the "POISED" process, and documented in RFC 1602 [5].  (The
 previous process was documented in RFC 1310 [4]; RFC 1602 has later
 been updated by RFC 1871 [7] and obsoleted by RFC 2026 [1].)
 Some of the functions were also defined in RFC 1603 [6], Working
 Group Guidelines, which was later obsoleted by RFC 2418 [2].
 As the community has grown, and the IESG has gathered experience, the
 ways in which the IESG has approached 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 in detail 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 [9].
 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.  Therefore, this document was written as a
 "documentation of existing practice" rather than as IETF consensus on
 what the IESG should do.
 This document is published as an Informational RFC, detailing the
 current operations of the IESG.  It does not claim to represent
 consensus of the IETF that this is the right set of instructions to
 the IESG.

2. The Composition of the IESG

 The IESG has the following members:
 o  The IETF Chair, who also functions as the General Area Director
    when this area is active
 o  The Area Directors (ADs) for the IETF Areas
 o  The Internet Architecture Board (IAB) Chair and the IETF Executive
    Director, as ex-officio members of the IESG.
 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 the person charged with running the
 IETF Secretariat.

Alvestrand Informational [Page 2] RFC 3710 An IESG Charter February 2004

 The IESG also has liaisons, who are members of the IESG mailing list
 and may attend all IESG meetings.  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
 are 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.
 IESG decisions are made by the IETF Chair and the Area Directors.
 All IESG members can participate in the IESG's discussions.

3. Procedural Issues

 While the IESG is generally free to set its own procedures, some
 parts of its 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.  There is no general rule on how the IESG takes votes; if
 this had ever been needed, it is likely that the same rule as for the
 IAB would be used (decisions may be taken if at least two thirds of
 the 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.
 The IESG may decide that other procedures for reaching a decision are
 appropriate 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

Alvestrand Informational [Page 3] RFC 3710 An IESG Charter February 2004

    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
    needing to consult the IESG first.
 The IESG may reach decisions by face to face meeting,
 teleconferencing, Internet communication, or any combination of the

3.2. Openness and Confidentiality

 The IESG publishes a record of decisions from its meetings on the
 Internet, and conducts an open meeting at every IETF meeting.  It
 publishes more detailed documentation of decisions as RFCs, Internet
 Drafts or messages to the IETF-announce mailing list, with copies
 kept on the IETF website when appropriate.
 The IESG also has private group discussions, 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.
 The chair may also exclude members and liaisons who have a serious
 conflict of interest on an issue (although this has never been
 enacted).  Members can also choose to recuse themselves from
 discussion of an issue, or refrain from participating in a particular
 ballot, if they feel it is appropriate.

Alvestrand Informational [Page 4] RFC 3710 An IESG Charter February 2004

4. The IESG Role in Working Group Management

 The IESG is in charge of managing the working group process.  While
 the process of managing a working group is assigned 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 additional
 details of IESG actions.
 A Working Group (WG) may be requested by members of the IETF
 community, who address 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 and/or Area if the IESG thinks that is best.
 The AD is responsible for ensuring that a working group being
 chartered fulfills 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 from the rest of the
 IESG and the IAB.
 The AD, with the advice of the IESG, 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 the charter is ready for
 review, but prior to the IESGs final decision on chartering the WG.
 The final decision to charter a WG is an IESG decision.
 The Birds of a Feather (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 of creating a working
 group.  BOFs are also often discussed with the IESG and IAB.

Alvestrand Informational [Page 5] RFC 3710 An IESG Charter February 2004

4.2. Working Group Management

 The role of the Area Director in WG management is described in BCP 25
 [2], section 6.7.
 The role of managing a WG is divided between the WG Chair(s) and the
 A WG chair has to manage the working group "from the inside", dealing
 with individuals, drafts, proposals, meetings and email lists, and
 has full power and responsibility to do that.
 An AD manages a WG "from the outside", dealing with charters, chairs,
 cross-WG and cross-area relationships and so on.
 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 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 same
 type of process as chartering - see BCP 25 [2], section 5.
 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 complete, or when
 the AD concludes that letting the working group continue its work no
 longer contributes to the IETF's progress.
 The decision to terminate a working group is announced, giving the
 reason for termination.

Alvestrand Informational [Page 6] RFC 3710 An IESG Charter February 2004

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, which applies to Proposed, Draft, Standard and BCP
 processing, is described in BCP 9 [1], section 6.  Such documents are
 submitted to the IESG, and are then assigned to a relevant AD.  The
 IESG is responsible for determining:
 o  Whether or not the specification is appropriate for the 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.

Alvestrand Informational [Page 7] RFC 3710 An IESG Charter February 2004

 The IESG may decide that a document submitted for standards-track
 publication should instead be published as Experimental or
 Informational, or that a document submitted for Proposed standard
 should be published as a 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.
 An AD, in consultation with the author, may choose to put an
 individual's document directly before the IESG, without waiting for
 the document to be submitted through the RFC Editor.  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 procedures are defined by the IESG.
 The IESG is responsible for conducting the process in a timely manner
 with appropriate communication.
 For all documents, the IESG assigns a specific AD the responsibility
 of shepherding 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 for
 The IESG has web pages as part of the IETF web (;
 current details of procedures, as well as the means of finding the
 responsible AD for any document, are published there.

Alvestrand Informational [Page 8] RFC 3710 An IESG Charter February 2004

6. The IESG Role in Area Management

 The IETF divides its work into a number of areas, each comprised of
 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, change the number of ADs assigned
 to an area, 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 members
 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 handled by one or two Area
 Directors per area.  An AD may be advised by one or more
 directorates, which are created, selected, chaired and if necessary
 disbanded 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 most
 important to the Internet in that area are indeed being worked on.
 The IESG decides which areas working groups belong to.

7. Other IESG Roles

7.1. Staff Supervision

 The IETF Chair has primary responsibility for supervising the work of
 the IETF Secretariat, with the advice and consent of the IESG, the
 IAB Chair and the ISOC president.
 The supervision of the Internet Assigned Numbers Authority (IANA) and
 RFC-Editor functions is handled by the IAB.

Alvestrand Informational [Page 9] RFC 3710 An IESG Charter February 2004

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 [10]).  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; for this reason,
 the IAB chair and the liaison from the IAB recuse themselves from
 discussion of appeals to the IESG.

8. Security Considerations

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

9. Acknowledgements

 This work has been supported, aided and abetted by the whole IESG at
 the time of this writing, and has benefited from many other comments.
 Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret
 Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen, Robert Elz,
 Keith Moore, Pete Resnick, Dave Crocker, Vint Cerf, Steve Coya and
 all others who provided comments on various versions of this

Alvestrand Informational [Page 10] RFC 3710 An IESG Charter February 2004

10. References

10.1. 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 2727, February 2000.

10.2. Informative References

 [4]  Chapin, L., "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.
 [10] Carpenter, B., Ed., "Charter of the Internet Architecture Board
      (IAB)", BCP 39, RFC 2850, May 2000.

11. Author's Address

 Harald Tveit Alvestrand
 Cisco Systems
 5245 Arboretum Dr
 Los Altos, CA

Alvestrand Informational [Page 11] RFC 3710 An IESG Charter February 2004

12. Full Copyright Statement

 Copyright (C) The Internet Society (2004).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78 and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed
 to pertain to the implementation or use of the technology
 described in this document or the extent to which any license
 under such rights might or might not be available; nor does it
 represent that it has made any independent effort to identify any
 such rights.  Information on the procedures with respect to
 rights in RFC documents can be found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use
 of such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository
 The IETF invites any interested party to bring to its attention
 any copyrights, patents or patent applications, or other
 proprietary rights that may cover technology that may be required
 to implement this standard.  Please address the information to the
 IETF at


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

Alvestrand Informational [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3710.txt · Last modified: 2004/02/18 19:49 (external edit)