Stefan Ideler via db-wg wrote:

Being a member of multiple RIR's, the Ripe db is user friendly and a scriptable database. I don't want to divide my as-sets and prefix filter generation over 3 or more different database systems, with the additional maintenance and in some cases even less verification. Atleast my RIPE originating objects are secure and they make up the majority of my prefixes.

As a result our route objects regardless of origin are noted in the RIPE database. Our upstreams use it to generate their prefix filters (and not all of them support multiple databases) and as a result we require all our downstream customers to have their AS/route objects within the RIPE database as well.

Several years ago, we planned this sort of approach via IXP Manager, but when we wrote the code to do it, we realised that this was a very limited and limiting mechanism for handling prefix list generation. It caused a lot of extra work for us in terms of support requirements and explaining to people that they had to do this. Several member organisations refused to comply and said they had no intention of changing their policies. The result of this was that we ended up not carrying traffic that we could alternatively have carried, and we annoyed our members. Not the best idea, in retrospect. We ended up having to be a lot more flexible on the issue. The best way we found to handle it was to allow any customer to be associated with any arbitrary IRR policy. E.g. one customer could use source: RIPE, ARIN and RADB, and another could use LACNIC, ALTDB and LEVEL3. It's actually pretty straightforward to implement this, and gives the advantage that you're no longer creating extra work for customers by forcing them to register their route: objects in IRRDBs where they wouldn't otherwise do so. The code for this is freely available on github.com/inex/IXP-Manager. I'm mentioning this because there is a serious security problem associated with permitting out-of-region objects in the RIPE database: this causes repeated, serious security problems with routing leakage on the Internet. This feature is being persistently abused by scammers and other criminals and is devaluing the integrity of the data in the RIPE IRRDB. Unless this problem is fixed, it's going to continue to be a problem indefinitely. We cannot fix it unless people fix their code. Nick