Subject: [newtrk] mailing list for every document?

From: James M Galvin <[email-masked]>
Date: Tue, 17 Aug 2004 11:09:03 -0400 (Eastern Daylight Time)

This comment is a bit of detail considering where a lot of the
discussion is right now, but I want to suggest a clarification to
something in draft-ietf-newtrk-proposals-00.txt and thus see what others
think.

Section 4.4 (Better Process Documentation and Tracking) has the
following:

   All documents (Internet Drafts, RFCs) get a formal system of tracking
   issues, known implementations of individual features, known problems,
   statements of determination of stability, etc.  The 'stable snapshot'
   state described in Section 4.1 would become just one of the kinds of
   annotations that a working group can give to a document during its
   development.

I support this goal.  I think the RFC Editor Errata page is a step in
the right direction but we need more, centrally available, and this gets
us moving in that direction.

However, the next paragraph starts off this way:

   All documents must have a mailing list for discussion of the
   document, with an archive of the mail on the mailing list. The
   mailing archive should be enabled for advanced searching capability.

I have two concerns with this.  First, if a mailing list is really what
we want it should not be the working group mailing list.  It needs to be
a new mailing list, created for the document, and managed in
perpetuity.  It is that last point which is most important.

The IETF has long held the principle that a working group mailing list
lives forever and is forever available to discuss the topics that were
originally embraced by the working group.  This has served us well, for
the most part.  However, the fact is, we are beginning to see problems
with this model.

Mailing lists don't last forever if they are not managed.  Recent
process changes have given responsibility for a mailing list to the
Chair of a working group (or their designee) but what happens when there
is no working group and hence no Chair?  The companies that host the
mailing lists change, too, and what happens to the list then?
Long-term, inactive IETF mailing lists become little more than a magnet
for spam, and this is a problem for anyone who hosts such a list.

Yes, there is a partial solution in place because IETF.ORG does take on
mailing lists as needed.  The key point here is that it's only a partial
solution.

In any case, this is not the place to discuss the issue of working group
mailing lists, but the observation that there are problems with the
model is important.  I'd like to see some discussion on the
functionality we're looking for, notably that the list should exist in
perpetuity (or at least as long as the document "exists").  I think that
will steer us away from re-using the working group mailing list.

Second, I question whether a mailing list is the right technology for
this purpose.  The problem with a mailing list for this purpose is that
its maintenance is passive.

Consider, who would subscribe to the list?  Who would manage the list of
subscribers?  The list would presumably have very low usage, so what
happens when months or years down the road somebody sends a note and it
goes to nobody because the email addresses of the subscribers have
changed?

Here again, I think a discussion of the functionality we need would
steer us away from a mailing list as the primary technology in use.
There is some discussion of functionality in the second sentence when it
describes the inclusion of an archive with searching capabilities.

So, to close with a specific suggestion, I think Section 4.4 of the
document should focus on a publicly available archive with searching
capabilities.  I don't think we need to describe what the archive
technology is just yet.  I would remove the reference to a mailing list,
that is, the first sentence in the second paragraph in the section, and
update the second sentence to remove the reference to a mailing list.

Jim
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html