New ways to do things (Re: Doing the Right Things?)

[Harald Tveit Alvestrand]

--On tirsdag, juni 03, 2003 15:46:21 -0700 Dave Crocker <dhc at dcrocker.net> 
wrote:

> HTA> There are working groups that function in a number of different
> modes: ...
> HTA> Would we be better off if we developed a few terms different from
> "working HTA> group"
>
> This is one of those things that sounds completely reasonable, except
> for lacking the detail needed to be concrete.
>
> Yes, different projects have different goals. Some are cleanup
> exercises. Some are intended to invent whole new systems. Some are
> intended to create nicely-modular capabilities. Some involve
> well-understood problems and possible solutions. Some involve a great
> deal of fuzziness.
>
> But all of them are established to produce one or more documents,
> usually specifying a protocol.
>

Dave,

many of my examples weren't....

<SOLUTIONSPACE>

As for concrete proposals in order to "try this one on for size", I suggest 
that we think about creating an object called a "maintenance team":

- Responsibility for a specific document or document set
  (usually one protocol)
- A chair
- A mailing list, with a public archive
- A web page (probably)
- Milestones strictly set by the IETF standards process:
  - 6 months after publication: "Evaluate suitability for grade change"
  - Every 12 months: "Evaluate whether protocol should be retired"
  (usually these would be filled by an one-liner note saying "no").
- No termination clause

For instance, we could create the "SMTP maintenance team":

- Chair: John Klensin :-)
- Responsibility: RFC 2821 (SMTP) and RFC 1652 (8BITMIME)
- Mailing list: ietf-smtp at imc.org
- Web page:
  "RFC 2821 is ready for Draft if someone has the energy to write the
  interoperability report. Known claimed-conformant implementations
  are: ............."
  "RFC 1652 is at Draft, but refers to MIME, which is still at Draft.
  Cannot be advanced at this time."
  "No RFC Editor Errata for either protocol."
  "The following unclear items are known:......"
  "The following resources exist:....."

The advantage would be that someone who does NOT know who still cares about 
the development of the SMTP protocol or where to go with questions about it 
could relatively easily find the (still-active!) mailing list and a contact 
person for it. (I believe the mailing list has moved around 3 times since 
it was an active IETF WG mailing list. Only its members know where to find 
it, I think.)

And since it's not chartered to produce anything in order to justify its 
existence, and indeed can be specifically barred from promoting new 
specifications, the "noise attraction" effect should be quite a bit smaller 
than the effect we've seen in WGs that "hang around forever".

Once the time came that a new document needs to be written, the maintenance 
team could either decide that a WG needs to be (re)started, or that the 
effort is small enough and uncontroversial enough to let it go forward as 
an individual effort.

</SOLUTIONSPACE>

>From my example list, this might eliminate the need to have LDAPBIS as a 
working group, and might also give IDR a viable path towards splitting off 
its pure maintenance activities, so that the "new developments" can be 
separated from the "maintenance of existing specifications".

I'll repost this separately to solutions at alvestrand.no, if people want to 
comment on the specifics of the idea - its value here is to focus the mind 
on the idea that not everything needs to be a working group.