Subject: RE: Discipline of Internet Protocol Engineering

From: <[email-masked]>
Date: Wed, 4 Jun 2003 12:46:28 +0300

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:[email-masked]]
> Sent: 04 June, 2003 12:31
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]
> Subject: RE: Discipline of Internet Protocol Engineering
> 
> 
> 
> 
> --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).
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jun 2003 15:08:24 +0200

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Jun 2003 09:55:03 -0400

--On Wednesday, 04 June, 2003 15:08 +0200 Brian E Carpenter 
<[email-masked]> wrote:

> The most useful section of diffserv's charter, from the
> viewpoint of discussion management, was the part starting:
> 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.
>

Brian,

While I fully agree, I think that, in this area and several 
others, we've set up the wrong incentive structure.  When we 
have tight charters, they are often, perhaps typically, not 
enforced.  When an AD enforces one --with regard to benchmarks, 
scope, or procedure-- he or she usually becomes _really_ 
unpopular with the membership of the relevant WG... and most of 
the rest of the community, at best, ignores the action.

Often, we end up with sloppy charters because some group 
insists, very loudly, that _something_ must be done, and done 
quickly, because of perceived market or timing pressures.    ADs 
who try to resist those pressures are criticized as unresponsive 
and foot-dragging, and, in general, no one comes to their 
defense.

We've had proposals whose effect would be to attach real costs 
to sloppy charters and drifting WGs.  While both of the recent 
ones --PACT and the "WG ceiling" draft-- have their own serious 
limitations and problems, they were not even discussed and 
explored seriously (e.g., to look at the problems and figure out 
how to work around them), presumably because people in the 
community don't, in the last analysis, really want those 
constraints on _their_ WGs, regardless of how they might feel 
about those of others.

I'd like to see if, in Vienna and thereafter, we can get ADs to 
report on the draft charters they have turned down, or forced 
into major revisions, because they were sloppy and on the WGs 
they have efficiently shut down for drifting off-charter (or 
just plain drifting).  And then I think we should loudly cheer 
those ADs.

This is of a piece with part of  "WGs produce poor-quality 
work".  Ultimately, poor quality work comes out because the 
community tolerates poor quality work.  The AD, or advisor, or 
random WG participant, who pushes back (either when things are 
under way or "late") is routinely reviled for holding things up, 
causing delays, being opposed to the principle on which the work 
is based, etc.  At plenaries, on mailing lists and, when nomcom 
time comes around, in whispering campaigns, we hear complaints 
about someone who has "caused" a delay; we don't hear complaints 
about those who quietly let garbage go through.  That situation 
requires a careful balance, but, whatever that balance is, we 
clearly haven't found it: the community's position _in practice_ 
is pretty clear.

As an aside, if we do not somehow change this manifest community 
attitude, it will eventually kill SIRS too.  I'd predict that it 
would work well for a while --almost any "change", 
"improvement", or "new method" does-- but that, eventually, we 
will find reviewers who push back on poor quality being abused 
for holding things up that represent clear WG consensus... and 
getting no support for trying to enforce quality.  Some of the 
good ones will decide that they didn't sign up for the abuse and 
drop out, others will start adopting a more relaxed attitude and 
letting things go through... just as many ADs have done.

I suggest that much of the problem here is that, in Pogo's 
immortal words, "we have met the enemy and they are us".   And 
we had better figure out how to turn that around.

       john