Subject: RE: Discipline of Internet Protocol Engineering

From: <[email-masked]>
Date: Wed, 4 Jun 2003 09:33:24 +0300

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.

Thinking about this a bit more, maybe we need to have more formal guidelines
on what a charter should contain.

John

> -----Original Message-----
> From: ext [mailto:[email-masked]]
> Sent: 04 June, 2003 09:31
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Discipline of Internet Protocol Engineering
> 
> 
> Hi Dave & Keith,
> 
> > KM> The reason I say this is that several groups have 
> demonstrated the inability
> > KM> to define the problem they are working on,
> > 
> > Unfortunately, i think this problem is deeper than we might wish to
> > acknowledge.  I tend to be a charter fascist, on the theory that a
> > crystal clear charter will leave no doubt about the problem being
> > solved, and/or the benefit to be derived from the result and the
> > deliverables to be produced.
> > 
> > I view charters as real contracts, making clear what is included and
> > obligated and what is excluded and prohibited.
> > 
> > However with great regularity, remarkably fuzzy charters are getting
> > approved. since chartering involves lots of experienced 
> people beyond
> > the working group, we can't simply assess the problem on the working
> > group folk.
> > 
> > I don't know how to improve this.  But, yes, we definitely 
> > need to keep trying.
> 
> I would say that there is a breakdown in the chartering 
> process.  I would
> think, for example, inviting the proposed WG chairs to the 
> conference call
> when the charter is discussed could help, for example.  As a 
> novice chair,
> creating a charter is difficult. Better advice & engagement 
> from the IAB/IESG
> would be helpful.  For experienced WG chairs, there can be a 
> tendancy that
> many of the IAB/IESG seem to be more lenient with their 
> proprosed charters 
> because the experienced chair is a known quantity, so the 
> thought is that
> they know what they are doing.
> 
> John
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Jun 2003 11:31:23 +0200

--On onsdag, juni 04, 2003 09:33:24 +0300 [email-masked] 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 "[email-masked]"
         (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).