"changed" field should be deleted

from Michael van Elst <mlelstv at xlink.net>
Hi,
 
> > This would obviously help the registries but other users of the RIPE-DB
> > might be left out by this solution.
> 
> "Other users" are not really interested in the real e-mail address
> of changer. This field is needed only by administrators who want to
> delete the object because they have to send back the exact copy of
> the record.
 
well, that's a kind of broad statement comparable to the "no user
would need more than 640k". Won't you think ?
 
For me the changed records help to track down the person who modified
the record and who could possibly tell what was changed and why it
was changed. Of course you cannot trust the records, but it gives
strong hints.

from gerald at merit.edu

In my mind it is tough to make the argument to keep email
addresses in the changed field because it helps you know
the person to make the last change.  You can specify
the "mnt-nfy:" attribute in the maintainer or "notify:"
attribute in the object to have an email message sent
which give the email header of the person who made
the udpate.
  You always have a problem in situations like
this when you want to make a change to the database
registry to something that has been around a long
time.  There are always going to be users who
don't want to change things for whatever reason.
eg, I still have people tell me they use the 
old ANS "advisory:" field which I think has been
obsoleted for quite some time now.  So even a proposal
to get rid of the "advisory:" field would meet with
some resistence.
  My $0.02, the "changed:" field as it is is worse
than useless.  The information that goes in it
right now belongs either in a "descr:" field if
someone chooses or not in the db at all.  And there
is a legitimate privacy issue which needs to be addressed.
I am in favor of keeping the "changed:" field.  I feel
it should contain the UTC machine generated time stamp
of the last update and that's it.  We would know the
last update and I also feel we (someday) need a mechanism
for dealing with legacy objects, ie, objects that have
been abandoned.  A *real* time stamp along with real
routing announcement information would go a long way
into dealing with this problem.

--jerry