Dear Colleagues, The RIPE NCC has been aware of this situation for some time. It affects unprotected objects, but there are other actions that can be done to unprotected objects (changes, deletion) and we have always encouraged you to protect your objects and have provided mechanisms to do this. It is not true that if someone uses your maintainer in this way that you will never know about it. If you have a "mnt-nfy" attribute in your maintainer object, then a notification will be sent to the mailbox specified there. It is true that you can put someone else's maintainer on an object that you already maintain yourself, but what is the point ? We are currently working on a new implementation of the database, which does not have this bug. At RIPE-34, we said that we would freeze the old code. Fixing this bug is easy and takes very little time, but testing it takes a significant amount of time. However, if the community feels strongly about this, we can divert resources to it. The object mentioned below has been deleted. If you have any questions, please contact <ripe-dbm@ripe.net>. Regards, A. M. R. Magee ________________________________________ On behalf of the RIPE NCC Database Group Carsten Schiefner <carsten.schiefner@tcpip-gmbh.de> writes: * Folks, * * I would like to draw your attention to a fact that might be intended as * a feature but what I consider more or less as a fault: I can't find any * good reason that it is possible to protect objects which are previously * unprotected or protected with an own mnt object also with other strong * ("password") mnt objects without knowing the password of this * maintainer. * * So it is possible for almost everyone to enter a bunch of bogus objects * in the RIPE database without protection and then - as a 2nd step - to * update all these objects, now including our company's mnt objects - thus * we will become "responsible" for these bogus objects in a way, but we * won't get aware of it. * * This may not be so significant for person objects, but is definitely * much more serious regarding AS or route objects - so a redesign of this * protection mechanism should be discussed at least. * * Please see * * http://www.ripe.net/cgi-bin/whois?sg4456-ripe * * as an example. * * Best regards, * * Carsten Schiefner * -- * * Carsten Schiefner mailto:carsten.schiefner@tcpip-gmbh.de * TCP/IP GmbH, Berlin (Germany) http://www.tcpip-gmbh.de * Phone: +49.30.443366-0 Fax: +49.30.443366-15 Mobile: +49.172.5425797 * * TCP/IP GmbH runs the Contrib.Net backbone http://www.contrib.net * ====================================================================== * *