On Jun 8, 2008, at 6:33 AM, David B. Nelson wrote:
Dean Willis writes...
However, I have seen cases recently where people need to establish
whether a particular John Doe was or was not subscribed to a given
IETF list on a given date (sometimes several years ago).
The "What did you know, and when did you know it?" line of inquiry?
And the "Did you have a duty to disclose the IPR held by your company
that affected the standard being discussed on the mailing list that you
were subscribed to?" line of inquiry.
This is more than the information that a subscribed-list archive
(as above) would have...
Do the current lists at ieft.org archive all of the add and remove
request
messages, in addition of the content messages?
hard to say. I've asked at times if such information was available, and
have received a variety of responses. So far, I've been able to find
"participatory examples" when needed, so those message archives are
very, very important!
... and it's the kind of thing IETF might be subpoenaed for.
Has that sort of thing ever happened to the IETF? You can't produce
records
you don't maintain. Unless you can quote some statutory requirement that
the IETF keep such records, it would be at our discretion.
Well, we might not be able to produce records, but we might have to
spend some effort convincing the judge that we can't produce those
records. This is easier if we have 1) a published policy on what is
maintained, and 2) actually comply with that policy. My opinion is that
it's generally to the IETF's benefit to have these records, but I'm sure
that's not a universal truth.
Overall, this suggestion sounds reasonable in terms of neat
organizational
housekeeping. My question is who does the work to seamlessly migrate
well-functioning existing lists to the ietf.org servers?
As a WG chair, I've migrated several non-IETF lists to IETF in a fairly
straightforward way:
1) Get the new list provisioned -- we have a process for this, and it
works pretty well.
2) Warn the old list about cutover and freeze its membership
3) Add the subscribers from the old list to the new list (admin
interface can do this)
4) Subscribe the new list to the old list
5) On cutover date, add an autoresponder to the old list to remind
people who post to the wrong one
6) Change the list pointers on various web sites.
7) Wait a while, then kill off the old list.
I believe we were even successful in getting some of the old mail
archives moved over for some of the lists, which is a nice touch.
From time to time, I've migrated a list without automatically moving
the subscribers. This is a very lazy way to purge stale entries that
don't happen to bounce, which happens more often than we probably think.
--
Dean