Discipline of Internet Protocol Engineering
Harald Tveit Alvestrand
harald at alvestrand.no
Wed Jun 4 12:31:23 CEST 2003
--On onsdag, juni 04, 2003 09:33:24 +0300 john.loughney at nokia.com wrote:
> Just a short reply to myself - I forgot to add that one of the
> difficulties of creating a charter is that, often, you think you know
> what you want to accomplish it, but sometimes it is difficult to seperate
> from what from the how and the why.
VERY much so.
> Thinking about this a bit more, maybe we need to have more formal
> guidelines on what a charter should contain.
just in case someone hasn't read RFC 2418 yet this week, here's what the
current formal guidelines say............
2.2. Charter
The formation of a working group requires a charter which is
primarily negotiated between a prospective working group Chair and
the relevant Area Director(s), although final approval is made by the
IESG with advice from the Internet Architecture Board (IAB). A
charter is a contract between a working group and the IETF to perform
a set of tasks. A charter:
1. Lists relevant administrative information for the working group;
2. Specifies the direction or objectives of the working group and
describes the approach that will be taken to achieve the goals;
and
3. Enumerates a set of milestones together with time frames for their
completion.
When the prospective Chair(s), the Area Director and the IETF
Secretariat are satisfied with the charter form and content, it
becomes the basis for forming a working group. Note that an Area
Director MAY require holding an exploratory Birds of a Feather (BOF)
meeting, as described below, to gage the level of support for a
working group before submitting the charter to the IESG and IAB for
approval.
Charters may be renegotiated periodically to reflect the current
status, organization or goals of the working group (see section 5).
Hence, a charter is a contract between the IETF and the working group
which is committing to meet explicit milestones and delivering
specific "products".
Specifically, each charter consists of the following sections:
Working group name
A working group name should be reasonably descriptive or
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.
Chair(s)
The working group may have one or more Chairs to perform the
administrative functions of the group. The email address(es) of
the Chair(s) shall be included. Generally, a working group is
limited to two chairs.
Area and Area Director(s)
The name of the IETF area with which the working group is
affiliated and the name and electronic mail address of the
associated Area Director(s).
Responsible Area Director
The Area Director who acts as the primary IESG contact for the
working group.
Mailing list
An IETF working group MUST have a general Internet mailing list.
Most of the work of an IETF working group will be conducted on the
mailing list. The working group charter MUST include:
1. The address to which a participant sends a subscription request
and the procedures to follow when subscribing,
2. The address to which a participant sends submissions and
special procedures, if any, and
3. The location of the mailing list archive. A message archive
MUST be maintained in a public place which can be accessed via
FTP or via the web.
As a service to the community, the IETF Secretariat operates a
mailing list archive for working group mailing lists. In order
to take advantage of this service, working group mailing lists
MUST include the address "wg_acronym-archive at lists.ietf.org"
(where "wg_acronym" is the working group acronym) in the
mailing list in order that a copy of all mailing list messages
be recorded in the Secretariat's archive. Those archives are
located at ftp://ftp.ietf.org/ietf-mail-archive. For
robustness, WGs SHOULD maintain an additional archive separate
from that maintained by the Secretariat.
Description of working group
The focus and intent of the group shall be set forth briefly. 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 problem area, basis,
goal(s) and approach(es) planned for the working group. This
paragraph can be used as an overview of the working group's
effort.
To facilitate evaluation of the intended work and to provide on-
going guidance to the working group, the charter must describe the
problem being solved and should discuss objectives and expected
impact with respect to:
- Architecture
- Operations
- Security
- Network management
- Scaling
- Transition (where applicable)
Goals and milestones
The working group charter MUST establish a timetable for specific
work items. While this may be renegotiated 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
showing specific achievement; e.g., "Internet-Draft finished" is
fine, but "discuss via email" is not. It is helpful to specify
milestones for every 3-6 months, so that progress can be gauged
easily. This milestone list is expected to be updated
periodically (see section 5).
More information about the Problem-statement
mailing list