< draft-iesg-charter-00.txt		draft-iesg-charter-01.txt >
	Network Working Group H. Alvestrand		Network Working Group H. Alvestrand
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: June 6, 2003 December 6, 2002		Expires: July 7, 2003 January 6, 2003
	An IESG charter		An IESG charter
	draft-iesg-charter-00		draft-iesg-charter-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		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 current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 6, 2003.		This Internet-Draft will expire on July 7, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	This memo gives a charter for the Internet Engineering Steering Group		This memo gives a charter for the Internet Engineering Steering Group
	(IESG), a management function of the Internet Engineering Task Force		(IESG), a management function of the Internet Engineering Task Force
	(IETF).		(IETF).
			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
			<poised@lists.tislab.com>
	1. Introduction		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
			(IETF).
			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		The role of the IESG in the IETF management structure has been
	largely constant since 1992, when the structure of the Internet		largely constant since 1992, when the structure of the Internet
	standards process was defined by RFC 1310 (which was later updated by		standards process was defined by RFC 1310 (which was later updated by
	RFC 1602, RFC 1871 and RFC 2026).		RFC 1602, RFC 1871 and RFC 2026).
	Some of the functions were also defined in RFC 1603 (which was later		Some of the functions were also defined in RFC 1603 (which was later
	updated by RFC 2418).		updated by RFC 2418).
	As the community has grown, and the IESG has gathered experience, the		As the community has grown, and the IESG has gathered experience, the
	way in which the IESG approaches its tasks has varied considerably,		way in which the IESG approaches its tasks has varied considerably,
	but the tasks have remained relatively constant.		but the tasks have remained relatively constant.
	This document describes the tasks assigned to the IESG.		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.
	2. The composition of the IESG		2. The composition of the IESG
	The IESG has the following members:		The IESG has the following members:
	o The IETF Chair, who is also the General AD		o The IETF Chair, who is also the General AD
	o The Area Directors for the IETF Areas		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		o Liaisons
	The Chair and the Area Directors are selected by the IETF NomCom		The Chair and the Area Directors are selected by the IETF NomCom
	according to the procedures of RFC 2282 (Nomcom procedures). The		according to the procedures of RFC 2282 (Nomcom procedures).
	Liaisons are selected as appropriate by the liaising bodies. At the
	time of this writing, the liaisons present are:
	The RFC Editor		The RFC Editor
	The IANA		The IANA
	The IAB		The IAB
	In addition, members of the IETF Secretariat are subscribed to the		In addition, members of the IETF Secretariat are subscribed to the
	mailing list and present in the IESG meetings as needed in order to		mailing list and present in the IESG meetings as needed in order to
	serve as a support function.		serve as a support function.
			Decisions of the IESG are made by the IETF Chair and the Area
			Directors.
	3. The IESG role in working group management		3. The IESG role in working group management
	3.1 Working group creation		3.1 Working group creation
	The formation of working groups is described in RFC 2418 section 2.		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		Each area director is responsible for ensuring that a working group
	being chartered is relevant, has achievable goals and constitutes an		being chartered is relevant, has achievable goals and constitutes an
	acceptable risk, has sufficient interest and so on. The charter is		acceptable risk, has sufficient interest and so on. The charter is
	the result of a negotiation between the AD and the prospective		the result of a negotiation between the AD and the prospective
	chairs, with review by the IAB and approval by the IESG. Normally,		chairs, with review by the IAB and approval by the IESG. Normally,
	there will be communication with the community of interest for the		there will be communication with the community of interest for the
	working group too.		working group too.
	The AD is also responsible for selecting chairs for the working group		The AD is also responsible for selecting chairs for the working group
	that he thinks will be up to the task.		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		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		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		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		create a working group. BOFs are also often discussed with the IESG
	and IAB.		and IAB.
	If an AD determines that it is needed, he can take the initiative to		If an AD determines that it is needed, the AD can initiate the
	create a working group.		formation of a working group.
	3.2 Working group management		3.2 Working group management
	The role of the Area Director in WG management is described in RFC		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		2418 section 6.7. The AD is responsible for making sure the working
	groups stay focused on the charter tasks, make forward progress, are		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 area, and (with the IESG)
	coordinated with the rest of the IETF.		coordinated with the rest of the IETF.
	In a well functioning working group, main responsibility for these		In a well functioning working group, main responsibility for these
	things rests with the chairs; the AD will normally be able to		things rests with the chairs; the AD will normally be able to
	concentrate on supporting the working group chairs' work.		concentrate on supporting the working group chairs' work.
	When a WG finds that it is essential that work gets done which is not		When a WG finds that it is essential that work gets done which is not
	on its charter, the AD is responsible for figuring out whether to add		on its charter, the AD, consulting with the rest of the IESG as
	it to their charter, add it to another group's charter, task someone		required, is responsible for figuring out whether to add it to their
	outside the WG to work on it, or initiate creation of another WG.		charter, add it to another group's charter, task someone outside the
			WG to work on it, or initiate creation of another WG.
	The Area Director is also responsible for picking and, when		The Area Director is also responsible for picking and, when
	necessary, replacing working group chairs. This is usually done in		necessary, replacing working group chairs. This is usually done in
	consultation with the IESG.		consultation with the IESG.
	4. The IESG role in document review		4. The IESG role in document review
	4.1 Working group documents		4.1 Working group documents
	This role is described in RFC 2418 section 7.5, and RFC 2026 section		This role is described in RFC 2418 section 7.5, and RFC 2026 section
	skipping to change at page 5, line 28 ¶		skipping to change at page 6, line 28 ¶
	director. The IESG is responsible for determining:		director. The IESG is responsible for determining:
	o Whether or not the specification is appropriate for standards		o Whether or not the specification is appropriate for standards
	track		track
	o Whether or not the specification needs review by one or more		o Whether or not the specification needs review by one or more
	existing WGs		existing WGs
	o Whether or not the quality of the specification is adequate		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		4.2.2 Informational and Experimental
	These documents are usually submitted to the RFC Editor in accordance		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.		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		The IESG is asked to review all documents submitted in this fashion
	for conflicts with the IETF standards process or work done in the		for conflicts with the IETF standards process or work done in the
	IETF community; this is a modification of the RFC 2026 procedure, and		IETF community; this is a modification of the RFC 2026 procedure, and
	documented in RFC 2418 section 8.		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		4.3 IESG review procedures
	The IESG review procedure is defined by the IESG.		The IESG review procedure is defined by the IESG.
	At the time of this writing, 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 IESG has web pages as part of the IETF web (www.ietf.org);		The IESG has web pages as part of the IETF web (www.ietf.org);
	current details of procedures should be published there.		current details of procedures should be published there.
	5. The IESG role in area management		5. The IESG role in area management
	The IETF divides its work into a number of areas, each comprising		The IETF divides its work into a number of areas, each comprising
	working groups that relate to that area's focus. (RFC 2418 section		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		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		the IESG. The IESG decides which areas groups belong to. When
	reassigning areas, the IESG can move responsibility for areas between		reassigning areas, the IESG can move responsibility for areas between
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 25 ¶
	The IESG is responsible for making sure the IETF process is		The IESG is responsible for making sure the IETF process is
	functional in all aspects. This includes taking responsibility for		functional in all aspects. This includes taking responsibility for
	initiating consideration of updates of the process when required, as		initiating consideration of updates of the process when required, as
	well as addressing obvious miscarriages of process even when it does		well as addressing obvious miscarriages of process even when it does
	not fall into the categories described above.		not fall into the categories described above.
	6.3 External relations		6.3 External relations
	The main responsibility for handling external relations rests with		The main responsibility for handling external relations rests with
	the IAB. However, when technical cooperation is required, it is		the IAB, as described in the IAB Charter (RFC 2850). However, when
	essential that the work be coordinated with the relevant ADs. This		technical cooperation is required, it is essential that the work be
	often means that ADs will function in a liaison role with other		coordinated with the relevant ADs. This often means that ADs will
	organizations, but the same function may also be done by others when		function in a liaison role with other organizations, but the same
	that seems more appropriate.		function may also be done by others when that seems more appropriate.
	7. Security considerations		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
			discussions.
			8. Security considerations
	The security of the Internet depends on standards giving proper		The security of the Internet depends on standards giving proper
	thought to security. Apart from that, there seem to be no		thought to security. Apart from that, there seem to be no
	considerations of security relevant to this memo.		considerations of security relevant to this memo.
	References		References
	[1] Chapin, A., "The Internet Standards Process", RFC 1310, March		[1] Chapin, A., "The Internet Standards Process", RFC 1310, March
	1992.		1992.
	skipping to change at page 11, line 7 ¶		skipping to change at page 12, line 7 ¶
	Harald Tveit Alvestrand		Harald Tveit Alvestrand
	Cisco Systems		Cisco Systems
	Weidemanns vei 27		Weidemanns vei 27
	Trondheim 7043		Trondheim 7043
	NO		NO
	EMail: harald@alvestrand.no		EMail: harald@alvestrand.no
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 20 change blocks.
	33 lines changed or deleted		94 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/