There is a lot more on this thread so I appologise if this has already been addressed...
RIPE database does not control the actual routing.
Nor does any other registry today.
I'm not sure the current RADB project has any mention of real-time updates of gated from the database. With dozens of updates we do every day it nearly as good as useless.
The last customer request was for 5 minute intervals, which is well within the existing bounds for BGP convergance time, at least as reported by you for at least one Sprint box. Would you really want 20 peers "flapping" routes at you much faster than this? Would you like to do this to your peers? Following Dales comment, each provider may set its own parameters on generation of configurations, regardless of where it gets its data from. For those sites that choose to use the registry for generation of configurations, they have the ability to generate them in "real-time". This does not force other peers to accept these updates in "real-time", but does provide a consistent place for them to get the data when they do their own configuration runs.
If i can't implement my existing policy, i cannot use RADB, ok?
The RADB is an RPS database. The IRR is several RIPE-181 and RPS databases that are syncronized. The RPS database is a superset of RIPE-181. RIPE-181 is a superset of RIPE-81.
(Well, we _will_ use it -- to talk to people whose announcements are loaded with garbadge). We simply cannot use it to talk to major service providers because policies in place cannot be represented in RIPE-81.
--vadim
So, why not convince yourself to run an RPS database, participate in the RPS discussions, generate your own configs from your database in the timeframes you need, and make your database available to the IRR so the others have a consistent view of sprint policy? --bill