Clement Cavadore via db-wg wrote:

That one, but with a *strong* enhancement on a trust model for such objects. We just cannot simply allow non-ripe route objects to be inserted in the db without any legitimity checks.

there is no way which non-ripe route objects can be subjected to legitimacy checks. It can't be done because several other RIRs don't provide the authentication hooks to be able to do this. On the question of this work item, what I would like is a mechanism to distinguish between route objects which have been verified using the trust grandfathering mechanism deployed by the RIPE NCC, and those which have not. There are many ways of doing this, e.g. 1. Option B: remove all non RIPE objects from the db. 2. use different source: tags to distinguish between ripe space and non ripe space. 3. leave whois.ripe.net as it is, and create a different database consisting of only authenticated route: objects. 4. leave whois.ripe.net as it is and create a different database view which, if queried, will return only objects which have been authenticated. Options for handling this might include: 4.1. same db on different hostname providing a different view 4.2. a new ripe-181++ tag identifying authenticated objects My preferences in order are: 2, then 4.2, then 4.1, then 3, then 1. No doubt there are plenty of other ways to crack this particular nut. Denis's description of Option C perpetuates what is a operational problem which has serious and ongoing consequences in the area of prefix hijacking. It would not be realistic to characterise the current situation as "if it ain't broke...", because it is identifiably broken, and it is this breakage which has led to this discussion. If we could solve this problem in a way which was operationally portable to other RIRs, that would be a bonus. Nick