[db-wg] Foreign ROUTE objects in RIPE Database - final decision?

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