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