< draft-iesg-charter-02.txt   draft-iesg-charter-03.txt >
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: October 8, 2003 April 9, 2003 Expires: September 30, 2003 April 2003
An IESG charter An IESG charter
draft-iesg-charter-02 draft-iesg-charter-03
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
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 October 8, 2003. This Internet-Draft will expire on September 30, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). 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 It is meant to document the charter of the IESG as presently
understood. understood.
Discussion of this memo is encouraged on the POISED mailing list Discussion of this memo is encouraged on the POISED mailing list
<poised@lists.tislabs.com> <poised@lists.tislabs.com>
STATUS NOTE (to be removed from RFC): STATUS NOTE (to be removed from RFC):
This document is intended for publication as an Informational This document is intended for publication as an Informational
document, detailing the instructions to the IESG that the IESG thinks document, detailing the instructions to the IESG that the IESG thinks
it has been operating under. It does not claim to represent it has been operating under. It does not claim to represent consensus
consensus of the IETF that this is the right set of instructions to of the IETF that this is the right set of instructions to the IESG.
the IESG. At this time (spring 2003), the structure of the IETF is At this time (spring 2003), the structure of the IETF is undergoing
undergoing reevaluation, and the result is likely to include changes reevaluation, and the result is likely to include changes to the
to the IESG's role; spending time to get IETF consensus that this IESG's role; spending time to get IETF consensus that this document
document represents the IETF consensus on what the IESG should do, represents the IETF consensus on what the IESG should do, which a BCP
which a BCP publication would indicate, seems like a less than useful publication would indicate, seems like a less than useful exercise.
exercise.
1. Introduction 1. Introduction
1.1 The role of the IESG 1.1 The role of the IESG
The Internet Engineering Steering Group (IESG) is the group that The Internet Engineering Steering Group (IESG) is the group
exists to perform the overarching operational and technical responsible for direct operation of the IETF and for ensuring the
management functions of the Internet Engineeering Task Force (IETF). quality of work produced by the IETF.
As part of this function, the IESG is tasked with making the The IESG charters and terminates working groups, selects their
management decisions about working groups in the IETF, and with the chairs, monitors their progress and coordinates efforts between them.
final review and approval of documents produced by Working Groups and The IESG performs technical review and approval of working group
documents published as IETF standards-track documents, and review of documents and candidates for the IETF standards track, and reviews
other candidates for RFC publication. other candidates for publication in the RFC series. It also
administers IETF logistics, including operation of the Internet-Draft
document series and the IETF meeting event.
1.2 Historic note 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 1993, after the significant changes introduced
standards process was defined by RFC 1310 (which was later updated by by the "POISED" process, and documented in RFC 1602. (The previous
RFC 1602, RFC 1871 and RFC 2026). process was documented in RFC 1310; RFC 1602 has later been updated
by RFC 1871 and obsoleted by RFC 2026).
Some of the functions were also defined in RFC 1603, Working Group Some of the functions were also defined in RFC 1603, Working Group
Guidelines, which was later updated by RFC 2418 [2]. Guidelines, which was later obsoleted by RFC 2418 [2].
As the community has grown, and the IESG has gathered experience, the As the community has grown, and the IESG has gathered experience, the
ways in which the IESG has approeched its tasks have varied ways in which the IESG has approached its tasks have varied
considerably, but the tasks have remained relatively constant. considerably, but the tasks have remained relatively constant.
This document describes the tasks assigned to the IESG. It does not This document describes the tasks assigned to the IESG. It does not
attempt to describe the procedures the IESG uses to accomplish these attempt to describe in detail the procedures the IESG uses to
tasks; that is done elsewhere - consult the IESG's Web pages on the accomplish these tasks; that is done elsewhere - consult the IESG's
IETF Website for more information. Web pages on the IETF Website for more information.
At this time (spring 2003), the structure of the IETF is undergoing
reevaluation, and the result is likely to include changes to the
IESG's role. Therefore, this document was written as a "documentation
of existing practice" rather than as the IETF consensus on what the
IESG should do.
It is published as an Informational document, detailing the
instructions to the IESG that the IESG thinks it has been operating
under. It does not claim to represent consensus of the IETF that this
is the right set of instructions to the IESG.
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 may also function as an Area Director when o The IETF Chair, who also functions as the General Area Director
appropriate when this area is active
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 o The IAB Chair and the IETF Executive Director, as ex-officio
members of the IESG. members of the IESG.
o Liaisons
The IETF Chair and the Area Directors are selected by the IETF NomCom The IETF Chair and the Area Directors are selected by the IETF NomCom
according to the procedures of BCP 10 [3] (Nomcom procedures). according to the procedures of BCP 10 [3] (Nomcom procedures).
The IETF Executive Director is appointed by the IETF Chair, and is The IETF Executive Director is the person charged with running the
charged with running the IETF Secretariat; traditionally, this IETF Secretariat.
position has been held by a person employed full-time by the
organization performing the secretariat function.
The Liaison positions exist to facilitate the work of the IETF by The IESG also has liaisons, who are members of the IESG mailing list
expediting communication with other entities involved in the IETF and may attend all IESG meetings. The Liaison positions exist to
process; which positions to have is decided by the IESG. facilitate the work of the IETF by expediting communication with
other entities involved in the IETF process; which positions to have
is decided by the IESG.
The liaisons are selected as appropriate by the bodies they The liaisons are selected as appropriate by the bodies they
represent. At the time of this writing, the liaisons present represent. At the time of this writing, the liaisons present
represent the following bodies: represent the following bodies:
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 Decisions of the IESG are made by the IETF Chair and the Area
Directors. All IESG members can participate in the IESG's Directors. All IESG members can participate in the IESG's
discussions. discussions.
3. Procedural issues 3. Procedural issues
While the IESG is generally free to set its own procedures, some While the IESG is generally free to set its own procedures, some
parts of the procedures are properly part of its charter. These are parts of the procedures are properly part of its charter. These are
given here. given here.
3.1 Decision making 3.1 Decision making
The IESG attempts to reach all decisions unanimously. If unanimity The IESG attempts to reach all decisions unanimously. If unanimity
cannot be achieved, the chair may conduct informal polls to determine cannot be achieved, the chair may conduct informal polls to determine
consensus. The IESG may make decisions and take action if at least consensus. There is no general rule on how the IESG takes votes; if
two thirds of the members concur and there are no more than two this had ever been needed, it is likely that the same rule as for the
dissents. IAB would be used (decisions may be taken if at least two thirds of
the members concur and there are no more than two dissents).
For the purpose of judging consensus, only the IETF Chair and the For the purpose of judging consensus, only the IETF Chair and the
Area Directors are counted. Area Directors are counted.
The IESG may decide that other procedures for reaching a decision are The IESG may decide that other procedures for reaching a decision are
apporpriate under specific conditions. Such other procedures may appropriate under specific conditions. Such other procedures may
include: include:
o Assertions of IETF consensus, such as when evaluating a standards o Assertions of IETF consensus, such as when evaluating a standards
action. Here, in addition to the technical quality of the action. Here, in addition to the technical quality of the
specification, the IESG has to evaluate the community opinion specification, the IESG has to evaluate the community opinion
about the specification's subject matter; this has to happen with about the specification's subject matter; this has to happen with
due notice and opportunity for community feedback. due notice and opportunity for community feedback.
o IESG actions in areas where the IESG has the authority to take o IESG actions in areas where the IESG has the authority to take
action. This does not need special rules. action. This does not need special rules.
o AD actions taken with the advice and consent of the IESG; the IESG o AD actions taken with the advice and consent of the IESG; the IESG
is expected to be kept informed, and gives comment, but the is expected to be kept informed, and gives comment, but the
authority to act is delegated to the AD. authority to act is delegated to the AD.
o AD action; cases where an AD can take independent action without o AD action; cases where an AD can take independent action without
the need to consult the IESG first. the need to consult the IESG first.
The IESG may reach decisions by face to face meeting, teleconference, The IESG may reach decisions by face to face meeting, teleconference,
Internet communication, or any combination of the above. Internet communication, or any combination of the above.
3.2 Openness and confidentiality 3.2 Openness and confidentiality
The IESG publishes the record of decisions from all its meetings on The IESG publishes a record of decisions from its meetings on the
the Internet, and conducts an open meeting at every IETF meeting. It Internet, and conducts an open meeting at every IETF meeting. It
publishes all its final decisions as RFCs, Internet Drafts or publishes more detailed documentation of decisions as RFCs, Internet
messages to the IETF-announce mailing list, with copies kept on the Drafts or messages to the IETF-announce mailing list, with copies
IETF website where appropriate. kept on the IETF website where appropriate.
The IESG also discusses its business privately as a group, using any The IESG also has private group discussions, using any means of its
means of its choice, including email. Records of those discussions choice, including email. Records of those discussions are not
are not required to be made public. This is believed to be vital in required to be made public. This is believed to be vital in
permitting a frank exchange of viewpoints and worries, allowing permitting a frank exchange of viewpoints and worries, allowing
people to speak out freely on topics known to be controversial, and people to speak out freely on topics known to be controversial, and
permitting people to change their minds based on presented arguments. permitting people to change their minds based on presented arguments.
Decisions and their justification are a matter of public record. Decisions and their justification are a matter of public record.
However, discussion of personnel matters and possibly legal and However, discussion of personnel matters and possibly legal and
financial matters may sometimes be required to be kept confidential, financial matters may sometimes be required to be kept confidential,
and the chair may, with the consent of the full members, exclude and the chair may, with the consent of the full members, exclude
liaison and ex officio members whose presence is seen as liaison and ex officio members whose presence is seen as
inappropriate for the particular discussion from such discussions. inappropriate for the particular discussion from such discussions.
The chair may also apply exclusion to full members who have a serious The chair may also exclude members and liaisons who have a serious
conflict of interest on an issue. Members can also choose to recuse conflict of interest on an issue (although this has never been done
themselves from discussion of an issue, or refrain from casting a so far). Members can also choose to recuse themselves from discussion
vote on an issue, if they feel that is appropriate. of an issue, or refrain from casting a vote on an issue, if they feel
that is appropriate.
4. The IESG role in working group management 4. The IESG role in working group management
The IESG is in charge of managing the working group process. While The IESG is in charge of managing the working group process. While
the process of running a working group is delegated to the working the process of managing a working group is assigned to the working
group chairs, the IESG is in charge of those processes that are group chairs, the IESG is in charge of those processes that are
beyond the scope of the working group chair's role. Most of these beyond the scope of the working group chair's role. Most of these
functions are delegated by the IESG to a single Area Director - the functions are delegated by the IESG to a single Area Director - the
"responsible Area Director" for the group. "responsible Area Director" for the group.
4.1 Working group creation 4.1 Working group creation
The formation of working groups is described in BCP 25 [2] section The formation of working groups is described in BCP 25 [2] section
2; this document does not repeat the text there, but gives some more 2; this document does not repeat the text there, but gives some more
details of IESG actions. details of IESG actions.
A WG may be requested by members of the IETF community, who addresse A WG may be requested by members of the IETF community, who address
the request to an AD that the requesters feel is the appropriate AD the request to an AD that the requesters feel is the appropriate AD
for the task, or the formation can be initiated by an AD. The IESG for the task, or the formation can be initiated by an AD. The IESG
may assign the prospective working group to another AD if the IESG may assign the prospective working group to another AD and/or Area if
thinks that is best. the IESG thinks that is best.
The AD is responsible for ensuring that a working group being The AD is responsible for ensuring that a working group being
chartered fulfils the criteria for WG formation given in BCP 25. The chartered fulfills the criteria for WG formation given in BCP 25. The
charter is the result of a negotiation between the AD and the charter is the result of a negotiation between the AD and the
community of interest, with review and advice by the rest of the IESG community of interest, with review and advice by the rest of the IESG
and the IAB. and the IAB.
The AD is also responsible for selecting chairs for the working group The AD, with the advice of the IESG, is also responsible for
which the AD thinks will be up to the task. selecting chairs for the working group which the AD thinks will be up
to the task.
All charters for proposed working groups are announced to the All charters for proposed working groups are announced to the
community at large when the IESG thinks that the charter is ready for community at large when the IESG thinks that the charter is ready for
review, but before the IESG makes a final decision on chartering the review, but before the IESG makes a final decision on chartering the
WG. The final decision to charter a WG is an IESG decision. WG. The final decision to charter a WG is an IESG decision.
The BOF procedure described in BCP 25 [2] section 2.4 also requires The BOF procedure described in BCP 25 [2] section 2.4 also requires
approval from the relevant AD (the one who got the request or the AD approval from the relevant AD (the one who got the request or the AD
that the IESG thinks is the right AD to manage the task). A BOF is that the IESG thinks is the right AD to manage the task). A BOF is
not required to start a working group, and a BOF may be held without not required to start a working group, and a BOF may be held without
the purpose being to create a working group. BOFs are also often the purpose being to create a working group. BOFs are also often
discussed with the IESG and IAB. discussed with the IESG and IAB.
4.2 Working group management 4.2 Working group management
The role of the Area Director in WG management is described in BCP 25 The role of the Area Director in WG management is described in BCP 25
[2] section 6.7. The AD is responsible for making sure the working [2] section 6.7.
groups stay focused on the charter tasks, make forward progress, are
coordinated with the rest of the area, and are coordinated with the The role of managing a WG is divided between the WG Chair(s) and the
rest of the IETF. The ADs help each other with maintaining cross- AD.
area coordination.
A WG chair has to manage the working group "from the inside", dealing
with individuals, drafts, proposals, meetings and email lists, and
has full power and responsibility to do that.
An AD manages a WG "from the outside", dealing with charters, chairs,
cross-WG and cross-area relationships and so on.
The AD is responsible for making sure the working groups stay focused
on the charter tasks, make forward progress, are coordinated with the
rest of the area, and are coordinated with the rest of the IETF. The
ADs help each other with maintaining cross-area coordination.
In a well functioning working group, main responsibility for these 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, consulting with the rest of the IESG as on its charter, the AD, consulting with the rest of the IESG as
required, is responsible for figuring out whether to add it to their required, is responsible for figuring out whether to add it to their
charter, add it to another group's charter, task someone outside the charter, add it to another group's charter, task someone outside the
WG to work on it, or initiate creation of another WG. WG to work on it, or initiate creation of another WG.
Substantive changes to the body of a WG's charter require the Substantive changes to the body of a WG's charter require the same
approval of the IESG. type of process as chartering - see BCP 25 [2] section 5.
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 done in necessary, replacing working group chairs. This is done in
consultation with the IESG, but the decision is made by the consultation with the IESG, but the decision is made by the
responsible AD. responsible AD.
4.3 Working group termination 4.3 Working group termination
Terminating a WG is a decision of the responsible AD. Terminating a WG is a decision of the responsible AD.
A working group may be shut down when its work is completed, or when A working group may be shut down when its work is completed, or when
the AD concludes that letting the working group continue its work the AD concludes that letting the working group continue its work
does not contribute to the IETF's forward progress. does not contribute to the IETF's forward progress.
The decision to terminate a working group must be announced, and the The decision to terminate a working group is announced, giving the
reasons should be clearly given. reason for termination.
5. The IESG role in document review 5. The IESG role in document review
The IESG is expected to ensure that the documents are of a sufficient The IESG is expected to ensure that the documents are of a sufficient
quality for release as RFCs, that they describe their subject matter quality for release as RFCs, that they describe their subject matter
well, and that there are no outstanding engineering issues that well, and that there are no outstanding engineering issues that
should be addressed before publication. The degree of review will should be addressed before publication. The degree of review will
vary with the intended status and perceived importance of the vary with the intended status and perceived importance of the
documents. documents.
When there are problems or solutions that occur frequently, the IESG When there are problems or solutions that occur frequently, the IESG
may publish documents describing the problems and how to avoid them, may publish documents describing the problems and how to avoid them,
such as "IANA considerations" (BCP 26 [8]), or publish web pages with such as "IANA considerations" (BCP 26 [8]), or publish web pages with
commonly used guidelines. commonly used guidelines.
Rules - stuff that the community is expected to follow - are decided Rules - stuff that the community is expected to follow - are decided
by IETF consensus processing and commonly published as BCP RFCs. by IETF consensus processing and commonly published as BCP RFCs.
Guidance to the community that is of a more ephemeral and less Guidance to the community that is of a more ephemeral and less
normative nature is decided by the IESG and published on the IESG's normative nature is decided by the IESG and published on the IESG's
Web pages. Web pages.
5.1 Working group documents 5.1 Working group documents
This role is described in BCP 25 [2] section 7.5 and 8, and BCP 9 [1] This role is described in BCP 25 [2] section 7.5 and 8, and BCP 9 [1]
section 6. The IESG role is one of review and approval. section 6. The IESG role is one of review and approval.
5.2 Non-working group documents 5.2 Non-working group documents
5.2.1 Standards-track documents 5.2.1 Standards-track documents
This role is described in BCP 9 [1] section 6. Such documents are This role, which applies to Proposed, Draft, Standard and BCP
submitted to the IESG, which will assign them to a relevant AD. The processing, is described in BCP 9 [1] section 6. Such documents are
submitted to the IESG, which will assign them to a relevant AD. The
IESG is responsible for determining: 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
skipping to change at page 10, line 11 skipping to change at page 10, line 12
The IESG may decide that a document submitted for standards-track The IESG may decide that a document submitted for standards-track
publication should instead be published as Experimental or publication should instead be published as Experimental or
Informational, or that a document submitted for Proposed standard Informational, or that a document submitted for Proposed standard
should be published as BCP, or vice versa. should be published as BCP, or vice versa.
5.2.2 Informational and Experimental documents 5.2.2 Informational and Experimental documents
These documents are normally submitted to the RFC Editor in These documents are normally submitted to the RFC Editor in
accordance with the procedures of BCP 9 [1] section 4.2.3 and BCP 25 accordance with the procedures of BCP 9 [1] section 4.2.3 and BCP 25
[2] section 8. The IESG is asked to review all documents submitted [2] section 8. The IESG is asked to review all documents submitted in
in this fashion for conflicts with the IETF standards process or work this fashion for conflicts with the IETF standards process or work
done in the IETF community; this is a modification of the BCP 9 [1] done in the IETF community; this is a modification of the BCP 9 [1]
procedure, and documented in BCP 25 [2] section 8. procedure, and documented in BCP 25 [2] section 8.
The IESG may recommend that the document be published as-is, that it The IESG may recommend that the document be published as-is, that it
be reviewed by a working group, that the document be published with be reviewed by a working group, that the document be published with
an IESG note indicating issues such as conflict with the IETF an IESG note indicating issues such as conflict with the IETF
standards process, or may recommend that the document not be standards process, or may recommend that the document not be
published. published.
If the document is referred to a WG, the WG can recommend that the If the document is referred to a WG, the WG can recommend that the
document be adopted as a WG document, that it be published (possibly document be adopted as a WG document, that it be published (possibly
with comments), or that the IESG recommend to the RFC Editor that it with comments), or that the IESG recommend to the RFC Editor that it
not be published. The responsible AD for the WG is responsible for not be published. The responsible AD for the WG is responsible for
getting a response from the WG in a timely manner. getting a response from the WG in a timely manner.
NOTE IN DRAFT: The following text tries to capture the occasional An AD, in consultation with the author, may choose to put an
practice of processing individual documents through the IESG without individual's document directly before the IESG, without waiting for
first going through the RFC Editor. It is not clear that the the document to be submitted through the RFC Editor. This document
description is accurate, so this may change. The IESG is discussing. will then be processed in the same fashion as an Informational or
Experimental document from a working group.
When an AD decides that an Informational or Experimental document is
of particular importance to the community, the AD may also choose to
put it directly before the IESG. This document will then be
processed in the same fashion as an Informational or Experimental
document from a working group.
5.3 IESG review procedures 5.3 IESG review procedures
The IESG review procedure is defined by the IESG. The IESG review procedure is defined by the IESG.
The IESG is responsible for conducting the process in a timely manner
with appropriate communication.
For all documents, the IESG assigns a specific AD the responsibility For all documents, the IESG assigns a specific AD the responsibility
for the document; that AD will normally review the document, and for the document; that AD will normally review the document, and
possibly ask for revisions to it to address obvious problems, before possibly ask for revisions to it to address obvious problems, before
asking the entire IESG to consider it. asking the entire IESG to consider it.
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, as well as the means of finding the current details of procedures, as well as the means of finding the
responsible AD for any document, are published there. responsible AD for any document, are published there.
6. The IESG role in area management 6. 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. (BCP 25 [2] section working groups that relate to that area's focus. (BCP 25 [2] section
1). The area structure is defined by the IESG, and the IESG can add 1). The area structure is defined by the IESG, and the IESG can add
areas, redefine areas, merge areas or close down areas. areas, redefine areas, merge areas, change the number of ADs assigned
to an area, or close down areas.
Changes to the area structure affect the IETF in many ways; decisions Changes to the area structure affect the IETF in many ways; decisions
to change the area structure are taken in consultation with the to change the area structure are taken in consultation with the
community community.
When changing the area structure, the IESG can decide which ADs are When changing the area structure, the IESG can decide which members
responsible for new and changed areas, including making one sitting are responsible for new and changed areas, including making one
AD responsible for multiple areas, but the IESG can only add new sitting AD responsible for multiple areas, but the IESG can only add
members through the nomcom process. new members through the nomcom process.
The primary task of area management is done by one or two Area The primary task of area management is done by one or two Area
Directors per area. An AD may be advised by one or more Directors per area. An AD may be advised by one or more directorates,
directorates, which are selected and chaired by the AD (BCP 25 [2] which are created, selected, chaired and if necessary disbanded by
section 1). Directorates may be specific to an area, specific to a the AD (BCP 25 [2] section 1). Directorates may be specific to an
technology, or chartered in some other fashion. area, specific to a technology, or chartered in some other fashion.
The ADs for an area are jointly responsible for making sure the WGs The ADs for an area are jointly responsible for making sure the WGs
in the area are well coordinated, that there is coverage for the in the area are well coordinated, that there is coverage for the
technologies needed in the area, and that the challenges that are technologies needed in the area, and that the challenges that are
most important to the Internet in that area are indeed being worked most important to the Internet in that area are indeed being worked
on. on.
The IESG decides which areas working groups belong to. The IESG decides which areas working groups belong to.
7. Other IESG roles 7. Other IESG roles
7.1 Staff supervision 7.1 Staff supervision
The IETF Chair has primary responsibility for supervising the work of The IETF Chair has primary responsibility for supervising the work of
the IETF Executive Director and the IETF Secretariat, with the advice the IETF Secretariat, with the advice and consent of the IESG, the
and consent of the IESG, the IAB Chair and the ISOC president. IAB Chair and the ISOC president.
The supervision of the IANA and RFC-Editor functions is handled by The supervision of the IANA and RFC-Editor functions is handled by
the IAB. the IAB.
7.2 Process management 7.2 Process management
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 to the process when required, as initiating consideration of updates to the process when required, as
well as addressing obvious miscarriages of process even when they do well as addressing obvious miscarriages of process even when they do
not fall into the categories described above. not fall into the categories described above.
7.3 External relations 7.3 External relations
The responsibility for handling external relations rests with the The responsibility for handling external relations rests with the
IAB, as described in the IAB Charter (RFC 2850). However, when IAB, as described in the IAB Charter (RFC 2850). However, when
technical cooperation is required, it is essential that the work be technical cooperation is required, it is essential that the work be
coordinated with the relevant ADs. This often means that ADs will coordinated with the relevant ADs. This often means that ADs will
function in a liaison role with other organizations, but the IAB may function in a liaison role with other organizations, but the IAB may
decide that the same function may also be done by others when it decide that the same function may also be done by others when it
decides that this is more appropriate. decides that this is more appropriate.
7.4 Appeals actions 7.4 Appeals actions
The formal appeals procedure is described in BCP 9 [1] section 6.5. The formal appeals procedure is described in BCP 9 [1] section 6.5.
Most decisions by a working group chair can be appealed to the AD, Most decisions by a working group chair can be appealed to the AD,
and decisions by an individual AD can be appealed to the IESG. and decisions by an individual AD can be appealed to the IESG.
Decisions of the IESG can be appealed to the IAB. Decisions of the IESG can be appealed to the IAB; for this reason,
the IAB chair and the liaison from the IAB recuse themselves from
discussion of appeals to the IESG.
8. Security considerations 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.
9. Acknowledgements 9. Acknowledgements
This work has been supported, aided and abetted by the whole IESG of This work has been supported, aided and abetted by the whole IESG of
the time of writing, and has benefitted from many other comments. the time of writing, and has benefited from many other comments.
Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret
Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen and all others Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen, Robert Elz,
who provided comments on various versions of this document! Keith Moore, Pete Resnick, Dave Crocker, Vint Cerf, Steve Coya and
all others who provided comments on various versions of this
document!
Normative references Normative references
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP [2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
25, RFC 2418, September 1998. 25, RFC 2418, September 1998.
[3] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall [3] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall
skipping to change at page 17, line 5 skipping to change at page 17, line 5
Author's Address Author's Address
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
Appendix A. Change log
This section should be deleted when publishing as an RFC
Changes from -02 to -03 (apart from minor wording changes):
o Added discussion of Informational status to history note (1.2)
o Changed history to mention the Kobe/POISED change in procedure
(1.2)
o Changed the composition of the IESG to mention members separately
from liaisons (2)
o Removed most of the description of the ExecDirector(2, 7.1)
o Changed ballot procedure to be a parenthetical remark, to make
clear it's not running code (3.1)
o Clarified exclusion paragraph (3.2)
o Clarified split of responsibilities between AD and WG chair (4.2)
o Clarified (or made clearer that it doesn't have very rigid rules)
AD-shepherded info/experimental individual documents (5.2.2)
o Added responsibility for timeliness to IESG review (with no
promise that it is DONE in a timely fashion.....) (5.3)
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). 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
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 65 change blocks. 
132 lines changed or deleted 209 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/