Fault vs. feature in the 'mnt-by' mechanism

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 at ripe.net>.

Regards,

A. M. R. Magee
________________________________________
On behalf of the RIPE NCC Database Group



 Carsten Schiefner <carsten.schiefner at 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 at 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
 * ======================================================================
 * 
 *