< draft-ietf-iesg-wgguidelines-00.txt		draft-ietf-iesg-wgguidelines-01.txt >
	Network Working Group Internet Engineering Steering Group		Network Working Group IESG
	INTERNET-DRAFT Erik Huizer		INTERNET-DRAFT Erik Huizer
	SURFnet bv		SURFnet bv
	December 1992		D. Crocker
			Silicon Graphics, Inc.
			June 1993
	IETF Working Group Guidelines and Procedures		IETF Working Group
			Guidelines and Procedures
	Status of this Memo,		STATUS OF THIS MEMO
	This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
	other documents at any time. It is not appropriate to use Internet
	Drafts as reference material or to cite them other than as a
	``working draft'' or ``work in progress.''
	Please check the 1id-abstracts.txt listing contained in the
	internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
	nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
	current status of any Internet Draft.
	When finalized the draft document will be submitted to the RFC editor		This document is an Internet Draft. Internet Drafts are working
	as an informational document. Distribution of this memo is unlimited.		documents of the Internet Engineering Task Force (IETF), its
	Please send comments to the author.		Areas, and its Working Groups. Note that other groups may also
			distribute working documents as Internet Drafts.
	Abstract		Internet Drafts are draft documents valid for a maximum of six
	The Internet Engineering Task Force (IETF) has the primary		months. Internet Drafts may be updated, replaced, or obsoleted by
	responsibility for the development and review of potential Internet		other documents at any time. It is not appropriate to use
	Standards from all sources. The IETF is organized into Working Groups		Internet Drafts as reference material or to cite them other than
	(WG). This document describes the guidelines and procedures for		as a ``working draft'' or ``work in progress.''
	formation and operation of an IETF Working Group. It describes the
	formal relationship between a WG and the Internet Engineering and
	Steering Group (IESG). The basic duties of a WG chair and an IESG Area
	Director are defined.
	Contents		Please check the 1id-abstracts.txt listing contained in the
			internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
			nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
			current status of any Internet Draft.
	Introduction		When finalized the draft document will be submitted to the RFC
	Acknowledgements		editor as an informational document. Distribution of this memo is
			unlimited. Please send comments to the author.
	WG formation		ABSTRACT
	Charter
	Review of charter
	Announcement
	Birds of a Feather sessions (BOFs)
	WG meetings		The Internet Engineering Task Force (IETF) has the primary
			responsibility for developing and review of specifications
			intended as Internet Standards. IETF activities are organized
			into Working Groups (WG). This document describes the guidelines
			and procedures for formation and operation of an IETF Working
			Groups. It describes the formal relationship between a WG and the
			Internet Engineering and Steering Group (IESG). The basic duties
			of a WG chair and an IESG Area Director are defined.
	WG policies and procedures		IESG 1
			The expiration date of this Internet Draft is December 1993.
	Document procedures		TABLE OF CONTENTS
	Internet-Drafts
	RFCs
	Progression of documents
	Review of documents
	Termination of a WG		1. INTRODUCTION
			1.1. IETF Approach to Standardization
			1.2. Acknowledgments
	WG chair duties		2. GROUP PROCESS
			2.1. Working Group Purpose & Scope
			2.2. Wg Policies And Procedures
			2.3. Birds Of A Feather (Bof)
			2.4. WG Formation
			Criteria for Formation
			Charter
			Charter Review & Approval
			2.5. Working Group Sessions
			2.6. Termination Of A WG
	AD duties		3. MANAGEMENT
			3.1. WG Chair Duties
			3.2. Area Director Duties
			3.3. Contention And Appeals Overview
	Security Considerations		4. DOCUMENT PROCEDURES
			4.1. Internet Drafts
			4.2. Request For Comments (RFC)
			4.3. Submission Of Documents
			4.4. Review Of Documents
	Authors address		5. SECURITY CONSIDERATIONS
	References		6. REFERENCES
	Appendix: Sample Working Group charter		7. AUTHORS ADDRESS
	Introduction
	This document defines guidelines and procedures for Internet		APPENDIX: Sample Working Group charter
	Engineering Task Force Working Groups.
	The Internet, a loosely-organized international collaboration of		1. INTRODUCTION
	autonomous, interconnected networks, supports host-to-host
	communication through voluntary adherence to open protocols and
	procedures defined by Internet Standards, commonly known as "the TCP/IP
	protocol suite". The Internet Standards Process is defined in RFC
	1310bis [1].
	The primary responsibility for the development and review of potential		This document defines guidelines and procedures for Internet
	Internet Standards from all sources is delegated by the Internet		Engineering Task Force Working Groups. The Internet, a loosely-
	Society [2] to the Internet Engineering Task Force (IETF). The goals,		organized international collaboration of autonomous,
	structures and procedures of the IETF can be found in it's charter [3].		interconnected networks, supports host-to-host communication
			through voluntary adherence to open protocols and procedures
	The Internet Engineering Task Force is chaired by the IETF Chair and		IESG 2
	managed by its Internet Engineering Steering Group (IESG). The IETF is		defined by Internet Standards, a collection of which are commonly
	a large open community of network designers, operators, vendors, and		known as "the TCP/IP protocol suite". The Internet Standards
	researchers concerned with the Internet and the Internet protocol		Process is defined in RFC 1310bis [1]. The primary
	suite. It is organized around a set of technical areas, each managed by		responsibility for the development and review of potential
	one or two technical Area Directors (AD). In addition to the IETF		Internet Standards from all sources is conducted by the Internet
	Chairman, the Area Directors make up the IESG membership. Each Area		Engineering Task Force (IETF). The goals, structures and
	Director has primary responsibility for one area of Internet		procedures of the IETF can be found in it's charter [3].
	engineering activity, and hence for a subset of the IETF Working
	Groups. At present there are eight areas, though this number may change
	over time:
	1) Applications
	2) User Services
	3) Internet Services
	4) Routing
	5) Network Management
	6) Operational requirements
	7) Security
	8) Transport and Services
	Each Area has an Area Directorate to support the Area Directors a.o.		The IETF is a large, open community of network designers,
	with the review of documents produced in the area. The Area Directorate		operators, vendors, and researchers concerned with the Internet
	is formed by the Area Director(s) from senior members of Working Groups		and the technology used on it. The IETF is managed by its
	(WG) within the area.		Internet Engineering Steering Group (IESG) whose membership
			includes an IETF Chair, responsible for oversight of general IETF
			operations, and Area Directors, each of whom is responsible for a
			set of IETF activities and working groups. At present there are
			10 areas, though the number and purview of Areas changes over
			time:
	The work of the IETF is performed by subcommittees known as Working		<<ARE THESE THESE EXACT NAMES OF THE AREAS??>>
	Groups. There are currently more than 60 of these. Working Groups tend
	to have a narrow focus and a lifetime bounded by completion of a
	specific task, although there are exceptions.
	Any member of the Internet community with the time and interest is		1) User Services
	urged to attend IETF meetings and to participate actively in one or		2) Applications
	more IETF Working Groups. Participation is by individual technical		3) Service Applications
	contributors, rather than formal representatives of organizations.		4) Transport Services
			5) Internet Services
			6) Routing
			7) Network Management
			8) Operational Requirements
			9) Security
			10) Standards & Processes
	This document defines procedures and guidelines for formation and		Most Areas have an advisory group, called the Area Directorate,
	operation of Working Groups in the IETF. It defines the relations of		to assist the Area Directors, e.g., with the review of
	Working Groups to other bodies within the IETF. The duties of Working		specifications produced in the area. The Area Directorate is
	Group Chairs and Area Directors with respect to the operation of the		formed by the Area Director(s) from senior members of the
	Working Group are also defined.		community represented by the Area. A small IETF Secretariat
			provides staff and administrative support for the operation of
			the IETF.
	The reader is encouraged to read the IETF Charter [3] and the RFC on		The primary work of the IETF is performed by subcommittees known
	the Internet Standards process [1]. Familiarity with these documents is		as Working Groups. There are currently more than 60 of these.
	essential for an understanding of the procedures and guidelines		Working Groups tend to have a narrow focus and a lifetime bounded
	described in this document.		by completion of a specific task, although there are exceptions.
	Acknowledgements		Membership in the IETF is established simply by the fact of
	This document is largely due to the copy-and-paste function of a		participation in its activities. This participation may be by on-
	wordprocessor.Several passages have been taken from the documents cited		line contribution, attendance at face-to-face sessions, or both.
	in the reference section. Three people deserve special mention, as		No formal rules govern this membership. Any member of the
	especially large chunks of their documents have been integrated into		Internet community with the time and interest is urged to
	this one: Vint Cerf [8] from whom I borrowed the description of the
	IETF. Greg Vaudreuil and Steve Coya [9] provided several paragraphs and
	detailed feedback. All the errors you'll find are probably mine.
	Working Group formation		IESG 3
			participate in IETF meetings and any of its on-line working group
			discussions. Participation is by individual technical
			contributors, rather than by formal representatives of
			organizations.
	IETF Working Groups (WGs) are the primary mechanism for the development		This document defines procedures and guidelines for formation and
	of IETF protocols, standards, and recommendations. A Working Group may		operation of Working Groups in the IETF. It defines the relations
	be established under the direction of an Area Director (AD), or its		of Working Groups to other bodies within the IETF. The duties of
	creation may be initiated by an individual, or group of individuals.		Working Group Chairs and Area Directors with respect to the
	Anyone interested in creating an IETF Working Group must consult with		operation of the Working Group are also defined. The document
	the appropriate IETF Area Director under whose direction the Working		uses words like: "shall", "will", "must" and "is required" where
	Group would fall, to confirm that creating a Working Group is		it describes steps in the process that are essential. Words like
	appropriate.		"suggested", "should" and "may" are used where guidelines are
			described that are not essential, but are strongly recommended to
			help smooth WG operation.
	A Working Group is typically created to address a specific problem or		1.1. IETF Approach to Standardization
	produce a specific deliverable (document, RFC, etc.), and is expected
	to be short lived in nature. Upon completion of its goals and
	achievement of its objectives, the Working Group as a unit is
	terminated. Alternatively, at the discretion of the Area Director and
	the Working Group chair and membership, the objectives or assignment of
	the Working Group may be extended by enhancing or adding to the Working
	Group's statement of objectives
	When determining if creating a Working Group is appropriate, the Area		The reader is encouraged to read The IETF Charter [3] and The
	Director will consider several issues:		Internet Standards Process [1]. Familiarity with these documents
			is essential for a complete understanding of the philosophy,
			procedures and guidelines described in this document. The goals
			of the process are summarized in [1]:
	o Are the issues that the Working Group plans to address important?		In general, an Internet Standard is a specification that is
			stable and well-understood, is technically competent, has
			multiple, independent, and interoperable implementations
			with operational experience, enjoys significant public
			support, and is recognizably useful in some or all parts of
			the Internet.
	o Does the work that the WG intends to undertake fit in with the		...
	Architecture as understood by the IESG/IAB.
	o Does the Working Group's activities overlap with those of another		In outline, the process of creating an Internet Standard is
	Working Group? If so, it may still be appropriate to create another		straightforward: a specification undergoes a period of
	Working Group, but this question must be considered carefully by the		development and several iterations of review by the Internet
	Area Director as subdividing efforts often dilutes the available		community and perhaps revision based upon experience, is
	technical expertise.		adopted as a Standard by the appropriate body (see below),
			and is published.
	o Are there several people clearly interested in the Working Group's		In practice, the process is somewhat more complicated, due
	topic and willing to expend the effort to produce a result (such as		to (1) the number and type of possible sources for
	an RFC)? Working Groups require considerable manpower: a chairman is		specifications; (2) the need to prepare and revise a
	needed to run meetings, an editor to edit authors' submissions, and		specification in a manner that preserves the interests of
	authors to actually write text. IETF experience suggests that these		all of the affected parties; (3) the importance of
	roles typically cannot all be handled by one person, four or five		establishing widespread community agreement on its technical
	active members are typically required. If the necessary manpower is
	lacking, the person interested in creating the Working Group might
	consider actually writing the RFC alone and submitting it for
	review, rather than attempting to create a Working Group.
	Considering the above criterion, the Area Director will decide whether		IESG 4
	to pursue the formation of the group through the chartering process.		content; and (4) the difficulty of evaluating the utility of
			a particular specification for the Internet community.
	Charter		...
	The formation of a Working Group requires an approved statement of
	direction or objectives along with establishing the administrative
	aspects of the Working Group which involves identifying the WG Chair or
	co-Chairs, the WG secretary (which can also be the WG chair), and the
	creation of a mailing list. This information is included in the Working
	Group Charter.
	The content of the charter document is negotiated between a prospective		These procedures are explicitly aimed at developing and
	Working Group chair and the relevant Area Director. The work statement		adopting generally-accepted practices. Thus, a candidate
	must explain the general purpose of the group, define its technical		for Internet standardization is implemented and tested for
	scope, enumerate a set of goals and milestones together with time		correct operation and interoperability by multiple,
	frames for their completion, and document various administrative		independent parties, and utilized in increasingly demanding
	points. When both the prospective Working Group chair and the Area		environments, before it can be adopted as an Internet
	Director are satisfied with the charter text, it becomes the basis for		Standard.
	forming a Working Group. The charter document may be similarly
	renegotiated or modified at any time during the course of the Working
	Group's effort to reflect the changing goals of the group.
	Each charter consists of five sections. These sections include		The IETF standardization process has been marked by informality.
	information about the Working Group (the name, the chairmen,		As the community of participation has grown it has become
	objectives, goals and milestones, and the mailing lists. The goals and		necessary to document procedures, while continuing to avoid
	milestones are part of the IETF tracking system, and are designed to		unnecessary bureaucracy. This goals of this balancing act are
	allow a degree of project management and support. They may change		summarized in [1] as:
	periodically to reflect the current status or organization of the
	Working Group.
	1. Working Group Name:		The procedures that are described here provide a great deal
	A Working Group name should be reasonable descriptive or		of flexibility to adapt to the wide variety of circumstances
	identifiable. Additionally, the group needs to define an 8 character		that occur in the Internet standardization process.
	ASCII acronym to reference the group in the IETF directories,		Experience has shown this flexibility to be vital in
	mailing lists, and general documents.		achieving the following goals for Internet standardization:
	2. Working Group Chair(s):		* high quality,
	The Working Group may have one or two chair(s) to perform the		* prior implementation and testing,
	administrative functions of the group. It is strongly suggested that		* openness and fairness, and
	these individuals have Internet mail addresses.		* timeliness.
	3. Working Group Description:		1.2. Acknowledgments
	In one to two paragraphs, the focus and intent of the group should
	be set forth. By reading this section alone, an individual should be
	able to decide whether this group is relevant to their work.
	Recognizing the importance of security and network management in the		Much of this document is due to the copy-and-paste function of a
	Internet Architecture, this description of the work of the group		word processor. Several passages have been taken from the
	must specifically address the impact in terms of security and		documents cited in the reference section. The POISED WG provided
	management.		discussion and comments. Three people deserve special mention, as
			especially large chunks of their documents have been integrated
			into this one: Vint Cerf [8] from whom we borrowed the
			description of the IETF. And Greg Vaudreuil and Steve Coya [9]
			who provided several paragraphs. All the errors you'll find are
			probably ours.
	4. Goals and Milestones:		IESG 5
	The Working Group should, after the first meeting, be able to		2. GROUP PROCESS
	establish a timetable for work. While this may change over time, the
	list of milestones and dates facilitate the Area Director's tracking
	of Working Group progress and status, and it is indispensable to
	potential participants to be able to identify the critical moments
	for input. Milestones should consist of deliverables that can be
	qualified as such, e.g. 'Internet-draft finished' is fine, but
	'discuss via E-mail' is not. This milestone list is expected to be
	updated periodically. Updated milestones should be submitted along
	with meeting minutes to the IETF Secretariat
	(iesg-secretary@cnri.reston.va.us).
	5. Mailing Lists:		2.1. Working Group Purpose & Scope
	Most of the work of an IETF Working Group is conducted on Internet
	Mail exploder lists. It is required that an IETF Working Group have
	a general discussion list. An individual needs to be designated as
	the list service postmaster, usually through the list-request alias
	mechanism. A message archive should be maintained in a public place
	which can be accessed via FTP. The IETF-archive@cnri.reston.va.us
	should be included on the mailing list.
	Note: It is strongly suggested that the mailing list be on an connected		IETF working groups (WGs) are the primary mechanism for
	IP host, to facilitate use of the SMTP expansion command (EXPN) and to		development of IETF specifications and guidelines, many of which
	allow access via FTP to the mail archives. If this is not possible, the		are intended as standards or recommendations. A working Group may
	message archive and membership of the list must be made available to		be established at the instigation of an Area Director (AD), or
	those who make such a request by sending a message to the list-request		its creation may be initiated by an individual or group of
	alias. The list maintainer or archiver need not be the Working Group		individuals. Anyone interested in creating an IETF working group
	chairman or secretary, but may be a member of the Working Group itself.		must obtain the advise and consent of the appropriate IETF Area
			Director under whose direction the working group would fall.
	An example of a WG charter can be found in appendix A.		A working group is typically created to address a specific
			problem or produce a specific deliverable (guideline, standard,
			etc.), and is expected to be short-lived in nature. Upon
			completion of its goals and achievement of its objectives, the
			working group as a unit is terminated. Alternatively, at the
			discretion of the Area Director and the working group chair and
			membership, the objectives or assignment of the working group may
			be extended by enhancing or modifying the working group's
			statement of objectives
	Charter Review		2.2. Wg Policies And Procedures
	Once the Area Director has approved the Working Group charter, the
	charter is submitted to the Internet Engineering and Steering Group and
	Internet Architecture Board for review and approval.
	The IESG will primarily consider if :
	- the WG has no overlap with WGs in other areas;
	- there is sufficient expertise in the IETF to review the results of
	the WG;
	The Internet Architecture Board (IAB) will review the charter of the		The IETF has basic requirements for open and fair participation
	proposed WG to see whether the proposed work is relevant to the overall		and for thorough consideration of technical alternatives. Within
	architecture of the Internet Protocol Suite.		those constraints, working groups are autonomous and each
			determines the details of its own operation with respect to
			session participation, reaching closure, etc. The core rule for
			operation is that acceptance or agreement is achieved via working
			group "rough" consensus.
	The approved charter is submitted to the IESG secretary (currently at		A number of procedural questions and issues will arise over time,
	CNRI) who records and enters the information into the IETF tracking		and it is the function of the working group chair to manage the
	database and returns the charter in form formatted by the database.		group process, keeping in mind that the overall purpose of the
	Using this reformatted charter, the Working Group is announced by the		group is to make progress towards reaching "rough" consensus in
	Birds of a Feather (BOF)		realizing the working group's goals and objectives.
	For an individual, or small group of individuals, it is often not clear
	if the issue(s) at hand merit the formation of a WG. To alleviate this
	problem the IETF offers the possibility of a Birds of a Feather (BOF)
	session.
	A BOF is a session at an IETF where a brainstorm type of discussion is		There are no hard and fast rules on organizing or conducting
	held on a subject proposed by the chair(s) of the BOF. Any individual		working group activities, but a set of guidelines and practices
	(or group of individuals) can request permission to hold a BOF on a		have evolved over time that have proven successful. Some of these
	certain subject. The request has to be filed with the relevant Area
	Director. The person who requests the BOF is usually appointed as chair
	of the BOF. The chair of the BOF is also responsible for providing a
	report on the outcome of the BOF.
	Usually the outcome of a BOF will be one of the following:		IESG 6
	- There was enough interest in the subject to warrant the formation of		are listed here, with actual choices typically determined by the
	a WG;		working group members and the chair.
	- The discussion came to a fruitful conclusion, the results will be
	written down and published as a RFC. There is no need to establish
	a WG;
	- There was not enough interest in the subject to warrant the
	formation of a WG.
	There is an increasing demand for BOF sessions at IETF meetings.		1. For face-to-face sessions, the chair should publish a
	Therefore as a rule it is not allowed to have multiple BOF sessions on		draft WG-agenda well in advance of the actual session.
	the same subject at IETF meetings.		The agenda needs to contain at least:
	Working Group Meetings		- The items for discussion;
	The Working Group is expected to meet periodically to discuss and		- The estimated time necessary per item; and
	review task status and progress, and to direct future activities. It is
	expected, but not required that every Working Group meet at the
	trimester IETF plenary sessions. Additionally, interim meetings are
	encouraged by telephone conference, video teleconference, or by actual
	face to face meetings. Meetings should be publicized as widely as
	possible, by announcing their time and location on the Working Group
	mailing list etc. When a meeting is held outside of an IETF session,
	the WG meeting should be announced to the IETF mailing list too.
	All Working Group sessions (also the ones held outside of the IETF		- A clear indication of what documents the participants
	sessions) should be reported by making minutes available. These minutes		will need to read before the session in order to be
	should include the agenda for the meeting, an account of the discussion		well prepared. The documents should be publicly
	including any decisions made, and a list of attendees. The Working		available (preferably as Internet drafts; see next
	Group chair is responsible for insuring that meeting minutes are		section) with information needed to access them.
	written and distributed, though the actual task may be performed by the
	Working Group secretary or someone designated by the Working Group
	chair. The minutes submitted in ASCII text for publication in the IETF
	Proceedings, and for posting in the IETF Directories.
	If a WG wants to meet at an IETF meeting, it has to apply for a		2. All relevant documents for a session (including the
	timeslot. In order to be efficient with allocation of sparse time-		final agenda) should be published and available at least
	slots, and in order to coordinate as well as possible WGs that require		two weeks before the session starts.
	more or less the same subset of experts (such that these experts do not
	waste time due to gaps between meetings), the WG chair needs to apply
	for a meeting at an IETF to the secretariat, as soon as the first
	announcement of that IETF meeting is made by the IETF secretariat to
	the wg-chairs list.
	The application for a WG meeting at an IETF meeting needs to be made to		3. It is strongly suggested that the WG chair makes sure
	the IETF secretariat, and it needs to contain:		that an anonymous FTP directory be available for the
	- the amount of time requested;		upcoming session. All relevant documents (including the
	- the rough outline of the agenda that is expected to be covered;		final WG-agenda and the minutes of the last session)
	- the estimated number of people that will attend the WG meeting.		should be placed in this directory. This has the
			advantage that all participants can ftp all files in
			this directory and thus make sure they have all relevant
			documents. Also, it will be helpful to provide
			electronic mail- based retrieval for those documents.
	The secretariat will form a draft agenda and distribute it among the		4. While open discussion and contribution is essential to
	wg-chairs for approval.		working group success, the chair is responsible for
			ensuring forward progress. As appropriate it may be
			acceptable to have restricted participation (not
			attendance!) at IETF working group sessions for the
			purpose of achieving progress. The working group chair
			usually has the authority to refuse to grant the floor
			to any individual who is unprepared or otherwise
			covering inappropriate material.
	Alternatively some Area Directors may want to coordinate WG meetings in		5. The detailed specification effort within a working group
	their area and request that timeslots be coordinated through them.		may be assigned to self-selecting sub-groups, called
	After receiving all requests for timeslots by WGs in the area, the Area		Design Teams. They may hold closed sessions for
	Director(s) form a draft agenda for their area, which will be send to		conducting the specification effort. In some cases
	the WG chairs of the area. After approval it will be send to the IETF		Design Teams are necessary to make forward progress when
	secretariat. The secretariat allots the timeslots on basis of the		preparing a document. All work conducted by a Design
	agenda made by the Area Director(s). If the proposed agenda for an area		Team must be available for review by all working group
	does not fit into the IETF meeting agenda, the IETF secretariat will
	adjust it to fit, after consulting the Area Director(s) and the
	relevant chairs.
	WG policies and procedures		IESG 7
			members and the DT must be responsive to the direction
			of the working group's "rough" consensus.
	All Working Group actions should be public, and wide participation		6. Many working group participants hold that mailing list
	encouraged. Announcements of meeting dates and time must be sent to the		discussion is the best place to consider and resolve
	Working Group mailing list and to mdavies@cnri.reston.va.us a		issues and make decisions, while others maintain that
	reasonable time before the meeting.		such work should be accomplished primarily at IETF
			meetings. Choice of operational style is made by the
			working group itself. It is important to note, however,
			that Internet email discussion is possible for a much
			wide base of interested persons than is attendance at
			IETF meetings, due to the time and expense required to
			attend.
	All Working Groups are autonomous, and each may have their own policies		7. It can be quite useful to conduct email exchanges in the
	and procedures with respect to meeting participation, reaching closure,		same manner as a face to face session, with published
	etc. Generally, acceptance or agreement is achieved via Working Group		schedule and agenda, as well as on-going summarization
	consensus, though some Working Groups may decide that a simple		and consensus polling.
	majority, significant majority (two thirds) or unanimous agreement is
	required. A number of procedural questions and issues have risen over
	time, and it is the function of the Working Group chair to manage this
	process, keeping in mind that the overall purpose of the group is to
	make progress towards realizing the Working Group's goals and
	objectives.
	There are no hard and fast rules on organizing or conducting Working		8. Consensus can be determined by balloting, humming, or
	Group activities, but a set of guidelines and practices have evolved		any other means the WG agrees on (by rough consensus, of
	over time that have proven successful. Some of these "topics" are		course). IETF consensus does not require that all
	listed here. Note that the choice of options is typically determined by		members agree, although this is of course preferred. In
	the Working Group members and the chairman.		general the "dominant" view of the working group shall
			prevail. (However it must be noted that "dominance" is
			not to be determined on the basis of volume or
			persistence, but rather a more general sense of
			agreement.)
	1. The chair is encouraged to publish a draft agenda well in advance of		9. It is occasionally appropriate to re-visit a topic, to
	the actual meeting. The agenda needs to contain at least:		re-evaluate alternatives or to improve the group's
	- items for discussion;		understanding of a relevant decision. However,
	- estimated time necessary per item;		unnecessary repeated discussions on issues can be
	- clear indication of what documents the participants will need to		avoided if the chair makes sure that the main arguments
	read before the meeting in order to be well prepared. The		in the discussion (and the outcome) are summarized and
	documents should be publicly available (preferably as Internet-		archived, after a discussion has come to conclusion. It
	drafts, see next section) and the "where and how to get them"		is also good practice to note important
	should be indicated.		decisions/consensus reached by E-mail in the minutes of
			the next 'live' session, and to briefly summarise
			decision making history in the final documents the WG
			produces.
	2. All relevant documents for a meeting (including the final agenda)		10. To facilitate making forward progress, a working
	should be published and available at least two weeks before the		group chair may wish to direct a discussion to reject
	meeting starts.		the input from a member, based upon the following
			criteria:
	3. It is strongly suggested that the WG chair creates an anonymous FTP		(old) The input pertains to a topic that already
	directory specially for the upcoming meeting. All relevant documents
	(including the final agenda and the minutes of the last meeting)
	should be placed in this directory. This has the advantage that all
	participants can just ftp all files in this directory and thus make
	sure they have all relevant documents.
	4. After a period of open meetings, the Working Group chair may hold		IESG 8
	executive (closed) meetings of the Working Group consisting of the		has been resolved and is redundant with
	authors of a particular document and any serious reviewers. This is		information previously available;
	often necessary to make forward progress preparing a final document.
	All work conducted in executive session must be made available for
	5. It is acceptable to have restricted participation (not attendance!)
	at IETF Working Group meetings for the purpose of achieving
	progress. The Working Group chairman usually has the authority to
	refuse to grant the floor to any unprepared individual.
	6. Many Working Group participants hold that mailing list discussion is		(minor) The input is new and pertains to a topic that
	the place to resolve issues and make decisions, while others		has already been resolved, but it is felt to
	maintain that such should be accomplished only at IETF meetings.		be of minor import to the existing decision;
	Resolution and acceptance within the Working Group is resolved by		or
	the Working Group.
	7. Consensus can be determined by balloting, humming, or any other		(not yet) The input pertains to a topic that the
	means the WG will agree on (by consensus of course).		working group has not yet opened for
			discussion.
	8. Repeated discussions on the same issues over E-mail can be avoided		2.3. Birds Of A Feather (Bof)
	if the chair makes sure that after a discussion has come to a
	conclusion, the main arguments in the discussion (and the outcome)
	are summarized and archived. It is also good practice to note
	important decisions/consensus reached by E-mail in the minutes of
	the next 'live' meeting.
	Document procedures		For an individual, or small group of individuals, it is often not
			clear if the issue(s) at hand merit the formation of a WG. To
			alleviate this problem the IETF offers the possibility of a Birds
			of a Feather (BOF) session, as well as the early formation of an
			email list for preliminary discussion.
	Internet Drafts		A BOF is a session at an IETF meeting which permits "market
	The IETF provides the Internet Drafts directories are provided to the		research" and technical "brainstorming". Any individual may
	Working Groups as a resource to post and disseminate early copies of		request permission to hold a BOF on a subject. The request has to
	any and all documents of the Working Group. This common repository is		be filed with the relevant Area Director. The person who requests
	available to all interested persons to facilitate wide review and		the BOF is usually appointed as chair of the BOF. The chair of
	comment. It is encouraged that draft documents be posted as soon as		the BOF is also responsible for providing a report on the outcome
	they become reasonably stable.		of the BOF.
	It is stressed here that Internet Drafts are drafts and have no		Usually the outcome of a BOF will be one of the following:
	official status whatsoever.
	Request For Comments (RFC)		- There was enough interest and focus in the subject to
	The work of an IETF Working Group usually results in the publication of		warrant the formation of a WG;
	one or more Request For Comments Documents (RFCs) [4]. This series of
	documents are the journal of record for the internet community. A
	document can be written by an individual in the Working Group or by the
	group as a whole with a designated editor. The designated author need
	not be the group chair(s).
	Note: The reader is reminded that all Internet Standards are published		- The discussion came to a fruitful conclusion, with
	as RFCs, but NOT all RFCs specify standards!		results to be written down and published; however there
			is no need to establish a WG;
	For a description on the various subseries of RFCs the reader is		- There was not enough interest in the subject to warrant
	referred to [1,5,6,7].		the formation of a WG.
	Submission of documents		There is an increasing demand for BOF sessions at IETF meetings.
	When a WG decides that a working document is ready for progression to		Therefore the following rules apply for BOFs:
	RFC, the following has to be done:
	- The relevant document as approved by the WG has to be in the
	Internet-Drafts directory;
	- The relevant document has to be formatted according to RFC-rules
	(see RFC-1111 [4]).
	- The WG chair sends an E-mail, containing the reference to the
	document, and the request that it be progressed as an
	(Informational, experimental, prototype or proposed STD) RFC to the
	Area Director(s), with a cc: to the IESG Secretary.
	The Area Director(s) will acknowledge receipt of the E-mail. From then		1. All BOFs wishing to meet during an IETF meeting must
	onwards the progressing of the document is the responsibility of the		have the approval of the appropriate Area Director. The
	IESG.		Secretariat will NOT schedule or allocate time slots
			without the explicit approval of the Area Director.
	Review of documents		IESG 9
	In case the submission is intended for Informational only no review is		2. The purpose of a BOF is to conduct a single, brief
	necessary. However if the WG or the RFC editor thinks that a review is		discussion or to ascertain interest and establish goals
	appropriate the AD can be asked to provide a review. In case of		for a working group. All BOF organizers are required to
	submission as an Experimental, Prototype or Standards RFC, the document		submit a brief written report of what transpired during
	will always be reviewed by the IESG. The review can either be done by		the BOF session together with a roster of attendees to
	the AD and other IESG members or by independent (i.e. not having been		the IETF Secretariat for inclusion in the proceedings.
	part of the WG in question) reviewers from the Area Directorate.
	Before making a final decision on a document, the IESG will issue a		3. A BOF may be held only once (ONE slot at one IETF
	"last call" to the IETF mailing list. This "last call" will announce		Plenary meeting).
	the intention of the IESG to consider the document, and it will solicit
	final comments from the IETF within a period of two weeks.
	The review will lead to one of three possible conclusions:		4. Under unusual circumstances an Area Director can, at
	1- The document is accepted as is; This fact will be announced by the		his/her discretion, allow a BOF to meet for a second
	IESG to the IETF mailing list and to the RFC Editor. Publication is		time. Typically (though not a requirement) this is to
	then further handled between the RFC editor and the author(s).		develop a charter to be submitted to the IESG.
	2- One or more changes regarding content are suggested to the
	author(s)/WG. Once the author(s)/WG has made these changes or has
	argued to the satisfaction of the reviewers why the change(s) is/are
	not necessary, the document will be accepted for publication as
	under point 1 above.
	3- The document is rejected; This will need strong and good
	argumentation from the reviewers. The whole process is structured
	such that this situation is not likely to arise for documents coming
	from a Working Group. After all the intents of the document would
	already have been described in the WG charter, and this has already
	been reviewed at the outstart of the WG.
	If any individual or group of individuals feels that the review		5. BOFs are not permitted to meet three times.
	treatment has been unfair, there is the possibility to make a
	procedural complaint. The mechanism for procedural complaints is
	described in the Charter of the IETF [3].
	Termination of a WG		6. Non-IETF groups wishing to participate in IETF meetings
			may hold a BOF for single-event discussion, or may
			pursue creation of normal IETF working groups for on-
			going interactions and discussions. The rules governing
			such BOFs are the same as for all other IETF BOFs and
			working groups.
	Working Groups are typically chartered to accomplish a specific task.		7. When necessary, IETF WGs will be given priority for
	After that task is complete, the group will be disbanded. If after a		meeting space over IETF BOFs.
	meeting a few times, it becomes evident that the group is unable to
	complete the work outlined in the charter, the group, in consultation
	with its Area Director can either 1) recharter to refocus on a smaller
	task, 2) choose new chair(s), or 3) disband.
	In those situations where the Working Group chairperson and the Area		2.4. WG Formation
	Director disagree about the steps required to refocus the group or the
	need to disband the group, the IESG will make a determination with
	input from the Area Director and the Working Group chair(s). Major
	changes will need a review from the IAB.
	WG chair duties		Criteria for Formation
	The Working Group chair(s) have wide discretion in the conduct of		When determining if creating a working group is appropriate, the
	business. The WG chair has to make sure that the WG operates in a		Area Director will consider several issues:
	reasonably efficient and effective way towards reaching the goals and
	results described in the WG charter. This very general description
	encompasses at the very least the following detailed tasks:
	- Moderate the WG distribution list;		- Are the issues that the working group plans to address
	The chair makes sure that the discussions on this list are relevant		clear and relevant for the Internet community?
	and that they converge. The chair makes sure that discussions on the
	list are summarized and the outcome is well documented (to avoid
	repeats).
	- Organize, prepare and chair face-to-face meetings;		- Are the goals specific and reasonably achievable, and
	The chair plans and announces the meeting well in advance (see		achievable within the time frame specified by the
	section on WG meetings for exact procedures). The chair makes sure		milestones?
	that relevant documents and the final agenda are ready at least 2
	weeks in advance of the meeting. The Chair makes sure minutes are
	taken, and that an attendance list is circulated. It is strongly
	suggested that the WG chair creates an anonymous FTP directory
	specially for the upcoming meeting. All relevant documents should be
	placed in this directory.
	- Communicate results of meeting;		- Do the working group's activities overlap with those of
	The chair makes sure that minutes of the meeting are taken. After		another working group? If so, it may still be
	screening the minutes the final version will be send to the Area		appropriate to create another working group, but this
	Director(s) and the IETF secretariat, in time for publication in the		question must be considered carefully by the Area
	IETF proceedings. The WG chair provides the Area Directors with a
	very short report (preferably via E-mail) on the meeting directly
	after the meeting took place. These reports will be used for the
	- Distribute the work;
	Of course each WG will contain a lot of participants that may not be
	able to (or want to) do any work at all. Most of the time the work
	is done by a few experts. It is the tasks of the chair to motivate
	enough experts to allow for a fair distribution of the workload.
	- Progress documents.		IESG 10
	The chair will make sure that authors of WG documents incorporate		Directors as subdividing efforts often dilutes the
	changes as discussed by the WG. Once a document is approved by the		available technical expertise.
	WG the chair reports to the Area Director(s) and the IESG secretary.
	The chair indicates (per E-mail) which document has been approved,
	and asks the IESG to review it for publication as an RFC (specify
	experimental, proposed STD etc.). The Area Director will acknowledge
	the receipt of the E-mail, and from then on the action is on the
	IESG. See the section on review of documents for possible further
	involvement of the chair in document progressing.
	Area Director duties		- Are there several people clearly interested in the
			working group's topic and willing to expend the effort
			to produce the desired result (e.g., a protocol
			specification)? Working groups require considerable
			effort: a chair is needed to run sessions, an editor to
			maintain the working document(s), and contributors to
			write the text. IETF experience suggests that these
			roles typically cannot all be handled by one person;
			four or five active members are typically required. If
			the necessary staffing is lacking, the person interested
			in creating the working group might consider actually
			writing the specification alone and submitting it for
			review, rather than attempting to create a working
			group.
	The Area Directors are responsible for a coherent, coordinated and		- Does a base of interested consumers appear to exist for
	architecturally consistent output from the Working Groups in their area		the planned work? Consumer interest can be measured by
	as a contribution to the overall results of the IETF. This very general		participation of end-users within the IETF process, as
	description encompasses at the very least the following detailed tasks		well as less direct indications.
	related to the Working Groups:
	- Coordination of WGs;		Considering the above criteria, the Area Director will decide
	The Area Director(s) coordinate the work done by the various WGs		whether to pursue the formation of the group through the
	within (and sometimes even outside) the relevant Area. The		chartering process.
	Director(s) try to coordinate meetings in such a way that experts
	can attend the relevant meetings with a minimum of overlap and gaps
	between meetings. (See section on WG meetings for details)
	- Reporting;		Charter
	The Area Director(s) report on the progress in the Area to the IETF.
	- Reviewing;		The formation of a working group requires a charter which is
	The Area Directors appoint independent reviewers for document		negotiated between a prospective working group chair and the
	reviewing. The Area Director(s) track the progress of documents from		relevant Area Director and which:
	the Area through the IESG review process, and report back on this to
	the WG Chair(s).
	- Progress tracking;		1) Lists relevant administrative aspects of the working
	The Area Directors track and manage the progress of the various WGs		group, such as identifying the WG Chair or co-Chairs,
	with the aid of a regular status report generated by the IESG		the WG secretary (who may also be the WG chair), and the
	secretary. The Area Directors forward this regular status reports on		addresses of the mailing list and any archive.
	documents and milestones made by the IESG Secretary to the WG
	chairs. This in turn helps the chairs to manage their WGs.
	- Area Directorate;		2) Specifies the direction or objectives of the working
	The Area Director chairs the Area Directorate. He is responsible for		group and describes the approach that will be taken to
	regular meetings of the directorate.		achieve the goals; and
	Security Considerations		3) Enumerates a set of goals and milestones together with
			time frames for their completion.
	Security issues are not addressed in this memo.		3) Lists the milestones and dates for intermediate goals,
			and
	References		IESG 11
			When both the prospective chair and the Area Director are
			satisfied with the charter text, it becomes the basis for forming
			a working group. The charter document may be similarly
			renegotiated or modified at any time during the course of the
			working group's effort to reflect the changing goals of the
			group.
	[1] RFC1310bis		Charters are reviewed and approved by the IESG. They may be re
	[2] Charter Internet Society		negotiated periodically to reflect the current status,
	[3] New charter IETF		organization or goals of the working group. Hence, a working
	[4] RFC 1111 Request for Comments on Request for Comments, J. Postel,		group charter is a contract between the IETF and the working
	August 1990.		group which is committing to meeting explicit milestones and
	[5] RFC 1150 F.Y.I. on F.Y.I., G. Malkin and J. Reynolds, March 1990		delivering concrete "products".
	[6] RFC 1311 Introduction to the Standards Notes, ed. J. Postel,
	March 1992.
	[7] RFC 1360 IAB Official Protocol Standards, ed. J. Postel, Sept.
	1992.
	[8] RFC 1160, The Internet Activities Board, V.Cerf, may 1990
	(This should be OBE by [3] by the time this gets published)
	[9] Guidelines to Working Group Chair(s), S. Coya, IESG distribution
	only.
	Authors address		Specifically, each charter consists of five sections:
	Erik Huizer		1. Working Group Name:
	SURFnet bv
	P.O. Box 19035
	3501 DA Utrecht
	The Netherlands
	Phone: +31 30 310290		A working group name should be reasonably descriptive or
	Fax: +31 30 340903		identifiable. Additionally, the group shall define an
			acronym (maximum 8 printable ASCII characters) to reference
			the group in the IETF directories, mailing lists, and
			general documents.
	Email: Erik Huizer@SURFnet.nl		2. Working Group Chair(s):
	Appendix: Sample Working Group charter
	MIME-MHS Interworking (mimemhs)
	Charter		The working group may have one or two chair(s) to perform
			the administrative functions of the group. The chair(s)
			shall be reachable by Email.
	Chair(s):		3. Area and Area Director(s)
	Steve Thompson <sjt@gateway.ssw.com>
	OSI Integration Area Director(s)		The name of the IETF area with which the working group is
	Erik Huizer <huizer@surfnet.nl>		affiliated and the name and electronic mail address of the
	Dave Piscitello <dave@sabre.bellcore.com>		associated Area Director.
	Mailing lists:		4. Working Group Description:
	General Discussion:mime-mhs@surfnet.nl
	To Subscribe: mime-mhs-request@surfnet.nl
	Archive:
	Description of Working Group:		In one to two paragraphs, the focus and intent of the group
			shall be set forth. By reading this section alone, an
			individual should be able to decide whether this group is
			relevant to their own work. The first paragraph must give a
			brief summary of the basis, goal(s) and approach(es) planned
			for the working group. This paragraph will frequently be
			used as an overview of the working group's effort.
	MIME, (Multipurpose Internet Mail Extensions) currently an Internet		Recognizing the importance of security and network
	Draft, is expected to become an Internet Proposed Standard. MIME		management in the Internet Architecture, this description of
	redefines the format of message bodies to allow multi-part textual and
	non-textual message bodies to be represented and exchanged without loss
	of information. With the introduction of MIME as a Proposed Standard
	it is now possible to define mappings between RFC-822 content-types and
	X.400 body parts. The MIME-MHS Interworking Working Group is chartered
	to develop these mappings, providing an emphasis on both interworking
	between Internet and MHS mail environments and also on tunneling
	through these environments. These mappings will be made in the context
	of an RFC-1148bis environment.
	Goals and Milestones:		IESG 12
			the work of the group must specifically address the impact
			of the work on these two issues.
	Jan 92 Post an Internet Draft describing MIME-MHS Interworking.		5. Goals and Milestones:
	Jan 92 Post an Internet Draft describing the ``core'' set of		The working group charter must establish a timetable for
	Registered conversions for bodyparts.		work. While this may be re-negotiated over time, the list
			of milestones and dates facilitates the Area Director's
			tracking of working group progress and status, and it is
			indispensable to potential participants identifying the
			critical moments for input. Milestones shall consist of
			deliverables that can be qualified as such; e.g. 'Internet-
			draft finished' is fine, but 'discuss via E-mail' is not.
			This milestone list is expected to be updated periodically.
			Updated milestones are re-negotiated with the Area Director
			and the IESG, as needed and then are submitted to the IETF
			Secretariat
	Jul 92 Submit a completed document to the IESG describing MIME-MHS		ietfadm@cnri.reston.va.us
	Interworking as a Proposed Standard.
	Jul 92 Submit the ``core'' bodyparts document to the IESG as a		6. Mailing Lists:
	Proposed Standard.
			Most of the work of an IETF working group is conducted on
			Internet mailing lists. It is required that an IETF working
			group have a general discussion list. An individual needs to
			be designated as the list service postmaster, usually
			through a list-request alias mechanism. A message archive
			should be maintained in a public place which can be accessed
			via FTP. The address
			IETF-archive@cnri.reston.va.us
			shall be included on the mailing list. Retrieval from the
			archive via electronic mail requests also is recommended.
			NOTE: It is strongly suggested that the mailing list be on a
			host directly connected to the IP Internet to facilitate use of
			the SMTP expansion command (EXPN) and to allow access via FTP to
			the mail archives. If this is not possible, the message archive
			and membership of the list must be made available to those who
			request it by sending a message to the list-request alias. The
			list maintainer or archiver need not be the working group chair
			or secretary, but may be a member of the working group itself.
			An example of a WG charter is in appendix A.
			IESG 13
			Charter Review & Approval
			Once the Area Director has approved the Working Group charter,
			the charter is submitted to the Internet Engineering and Steering
			Group and Internet Architecture Board for review and approval.
			The IESG will primarily consider whether :
			- There is sufficient expertise in the IETF to produce the
			desired results of the WG;
			- There is a good indication that the intended user
			population wants this work;
			- The risks and urgency of the work are specified, to
			determine the level of attention required, and
			- The extent to which the work will affect an installed
			base of users is taken into account.
			- The WG has overlap with WGs in other areas;
			- Related work by other groups will be affected or will be
			sufficiently coordinated with the work of this group
			The Internet Architecture Board (IAB) will review the charter of
			the proposed WG to determine the relationship of the proposed
			work to the overall architecture of the Internet Protocol Suite.
			The approved charter is submitted to the IESG Secretary who
			records and enters the information into the IETF tracking
			database and returns the charter in a form formatted by the
			database. The working group is announced by the IESG Secretary
			to the IETF mailing list, by the IESG secretary.
			2.5. Working Group Sessions
			All working group actions shall be public, and wide participation
			encouraged. A working group will conduct much of its business
			via electronic mail distribution lists, but may meet periodically
			to discuss and review task status and progress, and to direct
			future activities. It is common, but not required that a working
			group will meet at the trimester IETF plenary meetings.
			Additionally, interim sessions may be scheduled for telephone
			conference, video teleconference, or by actual face to face
			sessions.
			As noted in the earlier section on Working Group Policies and
			IESG 14
			Procedures, each working group will determine the balance of
			email and face-to-face sessions that is appropriate for achieving
			its milestones. Electronic mail permits the widest
			participation; face-to-face meetings often permit better focus
			and therefore can be more efficient for reaching consensus and
			ensuring consensus among a core of the working group members.
			Sessions must be publicized widely and well in advance and must
			take place at a convenient location. The time and location of a
			session must be announced on the working group mailing list,
			through any other mechanisms that are appropriate, and must
			include the IETF mailing list:
			ietf@cnri.reston.va.us
			All working group sessions (including those held outside of the
			IETF meetings) shall be reported by making minutes available.
			These minutes should include the agenda for the session, an
			account of the discussion including any decisions made, and a
			list of attendees. The working group chair is responsible for
			insuring that session minutes are written and distributed, though
			the actual task may be performed by the working group secretary
			or someone designated by the working group chair. The minutes
			shall be submitted in printable ASCII text for publication in the
			IETF Proceedings, and for posting in the IETF Directories.
			If a WG needs a session at an IETF meeting, the chair must apply
			for one or more time-slots as soon as the first announcement of
			that IETF meeting is made by the IETF secretariat to the
			wg-chairs list. Session time is a scarce resource at IETF
			meetings, so placing requests early will facilitate schedule
			coordination for WGs requiring the same set of experts.
			The application for a WG session at an IETF meeting shall be made
			to the IETF secretariat. Alternatively some Area Directors may
			want to coordinate WG sessions in their area and request that
			time slots be coordinated through them. After receiving all
			requests for time slots by WGs in the area, the Area Director(s)
			form a draft session-agenda for their area, which is then sent to
			the WG chairs of the area. After approval it will be sent to the
			IETF secretariat.
			An application must contain:
			- The amount of time requested;
			- The rough outline of the WG-agenda that is expected to
			be covered;
			IESG 15
			- The estimated number of people that will attend the WG
			session;
			- Related wgs that must not be scheduled for the same time
			slot(s).
			The Secretariat allots time slots on the basis of the session-
			agenda made by the Area director(s). If the proposed session-
			agenda for an area does not fit into the IETF meeting-agenda, the
			IETF secretariat will adjust it to fit, after consulting the Area
			director(s) and the relevant chairs. The Secretariat will then
			form a draft session-agenda and distribute it among the wg-chairs
			for final approval.
			2.6. Termination Of A WG
			Working groups are typically chartered to accomplish a specific
			task. After that task is complete, the group will be disbanded.
			However, if the work of a WG results in a Proposed Standard, the
			WG will go dormant rather than disband (i.e., the WG will no
			longer conduct formal activities, but the mailing list and the
			membership will remain available to review the work as it moves
			to Draft Standard and Standard status).
			If, at some point, it becomes evident that a Working Group is
			unable to complete the work outlined in the charter, the group,
			in consultation with its Area Director can either:
			1) Recharter to refocus on a smaller task,
			2) Choose new chair(s), or
			3) Disband.
			When the working group chairperson and the Area Director disagree
			about the steps required to refocus the group or the need to
			disband the group, the IESG will make a determination with input
			from the Area Director and the working group chair(s).
			IESG 16
			3. MANAGEMENT
			3.1. WG Chair Duties
			The Working Group chair(s) have wide discretion in the conduct of
			business. The WG chair has to make sure that the WG operates in a
			reasonably efficient and effective way towards reaching the goals
			and results described in the WG charter. This very general
			description encompasses at the very least the following detailed
			tasks:
			- Moderate the WG distribution list
			The chair should attempt to ensure that the discussions on
			this list are relevant and that they converge. The chair
			should make sure that discussions on the list are summarized
			and that the outcome is well documented (to avoid
			repetition). The chair also may choose to schedule
			organized on-line "session" with agenda and deliverables.
			- Organize, prepare and chair face-to-face sessions
			The chair should plan and announce sessions well in advance.
			(See section on WG Sessions for exact procedures.) The
			chair should make sure that relevant documents and the final
			WG-agenda are ready at least 2 weeks in advance of the
			session. It is strongly suggested that the WG chair creates
			an anonymous FTP directory for the working group's
			documents. All relevant documents should be placed in this
			directory.
			- Communicate results of session
			The chair must ensure that minutes of the session are taken
			and that an attendance list is circulated. After screening
			the minutes the final version will be sent to the Area
			Director(s) and the IETF secretariat, in time for
			publication in the IETF proceedings. The WG chair should
			provide the Area Directors with a very short report (via E-
			mail) on the session directly after it takes place. These
			reports will be used for the Area Report as presented in the
			proceedings of each IETF meeting.
			- Distribute the work
			Of course each WG will have members who may not be able to
			(or want to) do any work at all. Most of the time the bulk
			IESG 17
			of the work is done by a few dedicated members. It is the
			task of the chair to motivate enough experts to allow for a
			fair distribution of the workload.
			- Progress documents
			The chair will make sure that authors of WG documents
			incorporate changes as discussed by the WG. Once a document
			is approved by the WG the chair reports to the Area
			Director(s) and the IESG secretary. The chair indicates (per
			E-mail) which document has been approved, and asks the IESG
			to review it for publication (specify Experimental, Proposed
			STD, etc.). The Area Director will acknowledge receipt of
			the E-mail, and from then on action is the responsibility of
			the IESG. See the section on Review of Documents for
			possible further involvement of the chair in progressing
			documents.
			3.2. Area Director Duties
			The Area Directors are responsible for ensuring that working
			groups in their area produce coherent, coordinated and
			architecturally consistent output from the Working Groups in
			their area as a contribution to the overall results of the IETF.
			This very general description encompasses at the very least the
			detailed tasks related to the Working Groups:
			- Coordination of WGs
			The Area director(s) coordinate the work done by the various
			WGs within (and sometimes even outside) the relevant Area.
			The Director(s) try to coordinate sessions in such a way
			that experts can attend the relevant sessions with a minimum
			of overlap and gaps between sessions. (See section on WG
			sessions for details)
			- Reporting
			The Area Director(s) report to the IETF on progress in the
			Area.
			- Reviewing
			The Area Directors may appoint independent reviewers prior
			to document approval. The Area Director(s) track the
			IESG 18
			progress of documents from the Area through the IESG review
			process, and report back on this to the WG Chair(s).
			- Progress tracking
			The Area Directors track and manage the progress of the
			various WGs with the aid of a regular status report
			generated by the IESG secretary. The Area directors forward
			this regular status reports on documents and milestones made
			by the IESG Secretary to the WG chairs. This in turn helps
			the chairs to manage their WGs.
			- Area Directorate
			The Area Director(s) chairs the Area Directorate. They are
			responsible for regular sessions of the directorate.
			3.3. Contention And Appeals Overview
			Formal procedures for requesting review and conducting appeals
			are documented in The Internet Standards Process [1]. A brief
			summary is provided, here.
			In fact, the IETF approach to reviews and appeals is quite
			simple: When an IETF member feels that matters have not been
			conducted properly, they should state their concern to a member
			of IETF management. In other words, the process relies upon
			those who have concerns raising them. If the result is not
			satisfactory, there are several levels of appeal available, to
			ensure that review is possible by a number of people uninvolved
			in the matter in question.
			Reviews and appeals step through three levels:
			- Area
			This includes the Working Group review and Area Director
			review. No appeal should come to the IESG before the Area
			Director has reviewed the point of contention.
			- IESG
			If the offended party is not happy with the Area-level
			review, then they may bring them to the IESG chair and the
			Area Director for Standards Management. The IESG chair has to
			be in this loop on this. The IESG chair and the Standards
			IESG 19
			Area Director will bring the issue before the IESG for
			discussion and take the resolution back to the parties.
			- IAB
			If the offended party is still not happy with the outcome at
			the IESG level, then they may take their concern to the IAB.
			Concerns entail either a disagreement with technical decisions by
			the working group or with the process by which working group
			business has been conducted. Technical disagreements may be
			about specific details or about basic approach. When an issue
			pertains to preference, it should be resolved within the working
			group. When a matter pertains to the technical adequacy of a
			decision, review is encouraged whenever the perceived deficiency
			is noted. For matters having to do with preference, working
			group rough consensus will dominate.
			When a matter pertains to working group process, it is important
			that those with a concern be clear about the manner in which the
			process was not open or fair and that they be willing to discuss
			the issue openly and directly. In turn, the IETF management will
			make every effort to understand how the process was conducted,
			what deficiencies were present (if any) and how the matter should
			be corrected. The IETF functions on the good will and mutual
			respect of its members; continued success requires continued
			attention to working group process.
			4. DOCUMENT PROCEDURES
			4.1. Internet Drafts
			The Internet Drafts directory is provided to working groups as a
			resource for posting and disseminating early copies of working
			group documents. This repository is replicated at various
			locations around the Internet. It is encouraged that draft
			documents be posted as soon as they become reasonably stable.
			It is stressed here that Internet Drafts are working documents
			and have no official status whatsoever. They may, eventually,
			turn into a standards-track document or they may sink from sight.
			IESG 20
			4.2. Request For Comments (RFC)
			The work of an IETF working group usually results in publication
			of one or more documents, published as a Request For Comments
			(RFCs) [4]. This series is the journal of record for the Internet
			community. A document can be written by an individual in a
			working group, by a group as a whole with a designated editor, or
			by others not involved with the IETF. The designated author need
			not be the group chair(s).
			Note: The RFC series is a publication mechanism only and
			publication does not determine the IETF status of a document.
			Status is determined through separate, explicit status labels
			assigned by the IETF. In other words, the reader is reminded
			that all Internet Standards are published as RFCs, but NOT all
			RFCs specify standards!
			For a description on the various subseries of RFCs the reader is
			referred to [1,5,6,7].
			4.3. Submission Of Documents
			When a WG decides that a working document is ready for
			publication, the following must be done:
			- The relevant document as approved by the WG must be in
			the Internet-Drafts directory;
			- The relevant document must be formatted according to RFC-
			rules (see RFC-1111 [4]).
			- The WG chair sends email to the relevant Area
			Director(s), with a copy to the IESG Secretary. The
			mail should contain the reference to the document, and
			the request that it be progressed as an Informational,
			Experimental, Prototype or standards-track (Proposed,
			Draft or Full -- STD) RFC.
			The Area Director(s) will acknowledge receipt of the E-mail. From
			then onwards the progressing of the document is the
			responsibility of the IESG.
			4.4. Review Of Documents
			In case the submission is intended as an Informational RFC only
			IESG 21
			no review is necessary. However if the WG or the RFC editor
			thinks that a review is appropriate, the AD may be asked to
			provide one. In case of submission as an Experimental RFC, the
			document will always be reviewed by the IESG. This review can
			either be done by the AD and other IESG members or the IESG may
			ask for an independent reviewer (i.e., by someone not part of the
			WG in question) from the Area Directorate or elsewhere.
			A review will lead to one of three possible conclusions:
			1. The document is accepted as is.
			This fact will be announced by the IESG to the IETF
			mailing list and to the RFC Editor. Publication is then
			further handled between the RFC editor and the
			author(s).
			2. Changes regarding content are suggested to the
			author(s)/WG.
			Suggestions must be clear and direct, so as to
			facilitate working group and author correction of the
			specification. Once the author(s)/WG have made these
			changes or have explained to the satisfaction of the
			reviewers why the changes are not necessary, the
			document will be accepted for publication as under point
			1, above.
			3. The document is rejected.
			This will need strong and thorough arguments from the
			reviewers. The whole IETF and working group process is
			structured such that this alternative is not likely to
			arise for documents coming from a Working Group. After
			all, the intentions of the document will already have
			been described in the WG charter, and reviewed at the
			start of the WG.
			If any individual or group of individuals feels that the review
			treatment has been unfair, there is the opportunity to make a
			procedural complaint. The mechanism for procedural complaints is
			described in the section on Contention and Appeal.
			Before making a final decision on a standards-track document, the
			IESG will issue a "Last Call" to the IETF mailing list. This Last
			Call will announce the intention of the IESG to consider the
			document, and it will solicit final comments from the IETF within
			a period of two weeks. It is important to note that a Last Call
			is intended as a brief, final check with the Internet community,
			IESG 22
			to make sure that no important concerns have missed or
			misunderstood. Last Call cannot serve as a more general, in-
			depth review.
			5. SECURITY CONSIDERATIONS
			Security issues are not addressed in this memo.
			6. REFERENCES
			[1]RFC1310bis, The Internet Standards Process
			[2]Charter Internet Society
			[3]New charter IETF
			[4]RFC 1111 Request for Comments on Request for Comments, J.
			Postel, August 1990.
			[5]RFC 1150 F.Y.I. on F.Y.I., G. Malkin and J. Reynolds, March
			1990
			[6]RFC 1311 Introduction to the Standards Notes, ed. J. Postel,
			March 1992.
			[7]RFC 1360 IAB Official Protocol Standards, ed. J. Postel,
			Sept. 1992.
			[8]RFC 1160, The Internet Activities Board, V.Cerf, may 1990
			(This should be OBE by [3] by the time this gets published)
			[9]Guidelines to Working Group Chair(s), S. Coya, IESG
			distribution only.
			7. AUTHORS ADDRESS
			Erik Huizer
			SURFnet bv
			P.O. Box 19035 Phone: +31 30 310290
			3501 DA Utrecht Fax: +31 30 340903
			The Netherlands Email:
			Erik.Huizer@SURFnet.nl
			IESG 23
			Dave Crocker
			Silicon Graphics, Inc.
			2011 N. Shoreline Blvd. Phone: +1 415 390 1804
			P.O. Box 7311 Fax: +1 415 962 8404
			Mountain View, CA 94039 Email: dcrocker@sgi.com
			APPENDIX: Sample Working Group charter
			Integrated Directory Services (ids)
			Charter
			Chair(s):
			Chris Weider <clw@merit.edu>
			Tim Howes <tim@umich.edu>
			User Services Area Director(s)
			Joyce Reynolds <jkrey@isi.edu>
			Mailing lists:
			General Discussion:ids@merit.edu
			To Subscribe: ids-request@merit.edu
			Archive: merit.edu:~/pub/ids-archive
			Description of Working Group:
			The Integrated Directory Services Working Group (IDS) is
			chartered to facilitate the integration and interoperability of
			current and future directory services into a unified directory
			service. This work will unite directory services based on a
			heterogeneous set of directory services protocols (X.500,
			WHOIS++, etc.). In addition to specifying technical requirements
			for the integration, the IDS Group will also contribute to the
			administrative and maintenance issues of directory service
			offerings by publishing guidelines on directory data integrity,
			maintenance, security, and privacy and legal issues for users and
			administrators of directories. IDS will also assume
			IESG 24
			responsibility for the completion of the outstanding Directory
			Information Services Infrastructure (DISI) Internet-Drafts, which
			are all specific to the X.500 protocol, and for the maintenance
			of FYI 11, ``A catalog of available X.500 implementations''. IDS
			will need to liase with the groups working on development and
			deployment of the various directory service protocols.
			The IDS Working Group is a combined effort of the Applications
			Area and the User Services Area of the IETF.
			Goals and Milestones:
			Ongoing Track emerging directory service protocols to
			specify standards for interoperation with existing
			protocols.
			Ongoing Liase with groups working on deployment and
			development of directory services to locate and
			fix interoperability problems.
			Ongoing Identify unfilled needs of directory service
			offerers, administrators, and users.
			Mar 93 Submit to the IESG the DISI ``Advanced Usages of
			X.500'' paper as an informational document.
			Mar 93 Submit to the IESG the DISI ``X.500 Pilot
			Project Catalog'' paper as an informational
			document.
			Mar 93 Submit to the IESG the 1993 revision of FYI 11,
			``A catalog of available X.500 implementations''
			as an informational document.
			Mar 93 Submit as an Internet-Draft a ``Specifications
			for interoperability between WHOIS++ and X.500''.
			Jul 93 Submit as an Internet-Draft a ``Guide to
			administering a directory service'', which covers
			data integrity, maintenance, privacy and legal
			issues, and security.
			Jul 93 Submit as an Internet-Draft a ``Catalog of
			available WHOIS++ implementations''.
			Nov 93 Submit to the IESG the ``Specifications for
			interoperability between WHOIS++ and X.500'' as a
			standards document.
			IESG 25
			Nov 93 Submit as an Internet-Draft a ``User's guide to
			directory services on the Internet''.
			Mar 94 Submit to the IESG the ``Guide to administering
			a directory service'' as an informational
			document.
			Mar 94 Submit to the IESG the 1994 revision of FYI 11.
			Mar 94 Submit to the IESG the ``Catalog of available
			WHOIS++ implementations'' as an informational
			document.
End of changes. 119 change blocks.
	568 lines changed or deleted		474 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/