Discipline of Internet Protocol Engineering

[Brian E Carpenter]

Indeed, scope and non-goals need to be in there too.

The most useful section of diffserv's charter, from the viewpoint
of discussion management, was the part starting:
  "The group will not work on: "

I've always regarded the vetting of WG charters as the most important
single thing that the IAB and IESG do. A good charter is the
most effective tool an AD or WG Chair can have to maintain
forward progress.

So, "sloppy charters" needs to be on the problem list.

   Brian

john.loughney at nokia.com wrote:
> 
> Hi Harald,
> 
> 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?
> 
> John
> 
> > -----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;
> >       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).
> >
> >