Events of Tuesday, 27 October 1998.

RIPE Database Administration wrote:

> Dear Colleagues,
>
> On Tuesday, 27 October 1998, a user of the RIPE Network Management
> Database accidentally deleted many [person] objects. The objects
> affected were either not maintained by a 'mntner' object or were
> maintained by a 'mntner' object with an authentication mechanism
> of NONE.  The RIPE NCC has investigated this and learned that it
> was a genuine mistake by this user.
>
> When a person object is deleted, its nic-handle is available for
> re-use immediately. Therefore, you may find that a nic-handle now
> points to a different person or role object.  We recommend that you
> check the consistency of your data i.e. see if the nic-handles in the
> admin-c, tech-c, and zone-c lines of your objects refer to the correct
> person or role objects.
>
> We understand that an attempt was made to re-create the deleted
> objects by the individual who originally deleted them.  Please search
> for your person objects using both the name and the nic-handle. It is
> possible that your object has been re-created, but with a different
> nic-handle. If so, you must update your inetnum, route, mntner, etc.
> objects that refer to the previous nic-handles in the admin-c, tech-c,
> and zone-c lines.  You should replace the old nic-handles with the
> new ones. To check whether a certain nic-handle is referenced
> anywhere, you can use the inverse look-up flag. For example, you can
> do: "whois -i admin-c,tech-c,zone-c <nic-handle>" to see if that
> nic-handle is referenced anywhere as admin-c, tech-c, or zone-c (e.g.
> as in domain objects).
>
> If one or more of your person and/or role objects have not been
> re-created, we suggest that you first try to re-create them using the
> original nic-handle.  This way, you do not have to change any of the
> references that use this nic-handle. If the nic-handle has been
> re-used, you should try to create the person or role object with the
> AUTO-1 keyword.  In this case, however, you will have to change the
> inetnum, domain, or other objects that reference this nic-handle to
> point to the new one.  (Use the the "-i" flag mentioned above to find
> which objects reference the old nic-handle).
>
> The RIPE NCC shall, as a part of its service to the RIPE community,
> support users to restore their data to a consistent state.  We
> estimate that this should take about one working day.  Please note
> that it is the users responsibility to restore their own data.
>
> We would like to stress that the RIPE NCC operates the RIPE Database,
> however the responsibility for managing user data lies with the users.
> Mechanisms to protect data against unauthorised or unintentional
> modification exist for several years now. The RIPE NCC has always
> emphasized the importance of authentication mechanisms and has been
> recently working to introduce even stronger procedures.  We encourage
> users to deploy these authentication mechanisms.  Please read
> ripe-157, section 2.3 on how this works.
>
> If you have any problems with the RIPE Database, please send an email
> to <ripe-dbm at ripe.net>.
>
> Regards,
>
> The RIPE NCC Database Group.

Dear Madam,/Sir

Mistakes are not improbable, however I can not condone your inadequate
backup procedures. Its totally out of imagination that you may have rouinned
the RIPE database. You have to keep yourself more dedicated to your work.


Dr. Dimitrios Kalogeras

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: Card for Dimitrios  Kalogeras
URL: </ripe/mail/archives/db-wg/attachments/19981030/cb1d0c8d/attachment.vcf>