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(a)ripe.net>.
Regards,
The RIPE NCC Database Group.
