Hi, following up on a particular point (only), dropping the anti-abuse WG, but keeping the other two because it relates to database authorization and the IRR:
> More to the point, since when has it become a routine part of "day > to day operations" to have RIPE members flooding the RIPE data base > with blatant bovine excrement? I guess one important reason is that in some specific cases it's difficult to automate the distinction between what you refer to as "bovine excrement" and legitimate route objects. (This refers to your substantiated claim that fraudulent route objects have been and are being registered in the IRR part of the RIPE database.) Looking at the description of the route object in the RIPE DB: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-5-description-of-the-route-object and the authorization requirements at https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/10-authorisation/10-7-protection-of-route-6-object-space my understanding is that it describes that when "route" objects are created which cover in-region address space, authorization is requied from both the maintainer of the AS object as well as from the maintainer of the address space, so registering in-region route objects without the consent of the address space holder is more or less prevented. However, if the address space is out-of-region, the authorization checks for the address space is dropped / ignored, and only the authorization for the AS object is used, allowing the registration of route objects without the consent of the address space holder. I suspect it is this loop-hole which is being abused to register the route objects you are mentioning. I suspect that out-of-region route objects in the RIPE DB are an operational requirement for other reasons. One way to close this loop-hole would be for the RIRs to agree on a uniform authorization model, and share the authorization information (and data) between themselves. I suspect this is no small task. Best regards, - Håvard
