Hello Wilfred,
One of the basic intentions was to have (a set of tools that allows to maintain) a routing registry that matches "reality" as close as possible.
Looking at the situation from a routing perspective, you need cooperation form both the old and the new ISP in real life. Asking a 3rd party to remove a route object from the DB does not necessarily mean that the "old" announcement is going to disappear. The old ISP may still advertise the prefix!
Well there are many reasons for the new isp beeing uable to place a route object in the database: - old isp has merged -> lack of know how - old isp is unwilling -> customer cant change his isp - old isp is overloaded -> takes 4-6 weeks until route-object is updated *IF* the old ISP is willing to help, the current procedure is fine. The main problem is to install an additional route object NOT to delete the old one. For some time both route objects could be necessary.
Of course some ISPs may filter according to the RR (and maybe ignore the "old" stuff, but others might not.
You need to have a route-object for proper routing. A "dead" routing-object doesnt cause much trouble.
What I do not undertstand fully right now is the potential impact on the operation of configuration tools if they start to see more than 1 origin entry for a particular prefix from diferent ASes.
normally Upstream XY creates once per night his prefix-filters. If he gets an announcement of a customer without proper route-object he ignores it. -> no routing object no ip :-) There are *many* cases where two or more route objects for the *same* network exist. I dont know of any problem with that situation.
I also have to still think through the security aspect of _indiscriminately_ allowing the creation or deletion of DB objects without consent/cooperation of the parties involved.
Well if you own a house you as a owner wants to be able to change the keys if necessary ? The owner of the inetnum-object has lower rights than the first isp who installed a route object. Beside Ripe NCC the Maintainer in the inetobject should be able to modify all objects tied to his inetnum. This is mainly the inetobject itself and the route-objects.
While I do not at all object to revisit this problem (may I suggest to take it through Routing and/or Address-Policy firts?) my _feeling_ is that we won't see a much better machinery by bending the DB code left and right, but rather by trying to make progress in developing and properly deploying (some sort of) Routing Layer Security?
According to the ripe they need input from the db-wg to do this. It not too much additional code to developp, it is rather a other way to check whether a maintainer is authenticated to create/delete a route object or not. Winfried Haug --- Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh@headlight.de Fax: +49 711 2840 999 | http://www.headlight.de