Discipline of Internet Protocol Engineering
john.loughney at nokia.com
john.loughney at nokia.com
Wed Jun 4 13:46:28 CEST 2003
Thanks for posting 2418 - I have not read it this week. One ommission
I see from the text you clipped is that there is no mention of
the WG scope. If I understand Keith's complaints, some of them
relate to WG scope and that WGs often exceed there scope. Could
this be part of the problem, that the definition of a WG Charter
(& formal guidelines thereof) are not crisp enough?
> -----Original Message-----
> From: ext Harald Tveit Alvestrand [mailto:harald at alvestrand.no]
> Sent: 04 June, 2003 12:31
> To: Loughney John (NRC/Helsinki)
> Cc: problem-statement at alvestrand.no
> Subject: RE: Discipline of Internet Protocol Engineering
> --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;
> 3. Enumerates a set of milestones together with time
> frames for their
> 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
> 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.
> 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
> 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