"changed" field should be deleted

Gabor,

On Fri, Jun 05, 1998 at 11:12:32AM +0200, kissg at sztaki.hu wrote:
> 
> If the victim gets some junk mail,
> (s)he retrieves all database objects (including *rt) relative to
> ALL hosts, domains, and IP addresses that can be found in the mail header,
> and s(he) send complaining mails to ALL the fifty e-mail addresses
> found in the database objects (including the *ch field). :-(

Why don't you use fake e-mail addresses in the 'changed:' field if you
are concerned about this ...

I recently posted some messages regarding the 'changed:' field at the
<rps at ISI.EDU>. Below follows a summary.

The whole changed field is a bad idea in general. It's use is not
clear and it's contents are not reliable.

We will first need to define where the 'changed:' field is actually
for:

- recording the history of changes:
  - timestamp when changes were made
  - identify who made the changes and how to retrieve the
    update message
  - identify which previous object was changed
  
Al these uses are not very well served by the 'changed:' field right
now. People can change them at will (fun to confuse people), the
timestamp is not UTC (very annoying for people living in other
timezones) and it doesn't provide the time of changes (interesting if
you make more then one change a day).

I would propose to get rid of the 'changed:' field altogether, but
first define a more sound replacement with the following requirements:

- the new field should be added by the database itself
- the new field have a full UTC timestamp
- the new field should uniquely identify an object (serial number)
- the new field should identify which object it replaces
- the new field should record which maintainer was resposible 
  for the changes if a maintainer was involved.
  Actually, it probably makes sense to allow updates by maintainers 
  only, even for objects that are not protected by maintainers.
- it makes sense to have some form of identification of the update
  message to facilitate lookups in case of problems. An mail message
  id or any other id that the db possibly generates itself could help.
  
These features don't necessarily should be folded into one attribute,
and they might also not be viewed upon query by default.

This would also solve another problem with the db:

You will be able to delete messages by doing something like:

password: MyPasswd
delete:   MNT-DAVID ObjectID

instead of the problematic 'duplicate the full object deletion
process'.

Note that software support for such a field is not difficult what so
ever. Most of the building blocks are present in the software. The
specification is the most difficult part.

> My first radical suggestion is:
>   Let's delete the *ch field from the database objects.
> 
> However I know that there should be some info about the
> history of records.
> 
> a few raw ideas:
> - modified database software that hides the *ch field. *ch's could
>   be retrieved with some extra efforts only
> - some coded ID instead of e-mail address. Ordinary peoples couldn't
>   decode it but authorized ripe-ops could. (E.g. via WWW or e-mail)
>   This info shouldn't be public.
> 
> What is your opinion?

I don't think it helps much to spend a lot of effort in trying to fix
an inherently broken attribute. We better spend our time to replace it
with something new that really addresses the problem. We will else end
up adding all kind of hacks every few months to work around the
unsolved problem.

David K.
---