as a passive (mostly) participant, this is mostly my recollection too. as a non passive participant... I think the previously stated position from APNIC region is clear: we have problems with the logistics which permit resources from our region to be included in IRR statements in the RIPE DB, when no formal check is made of permission or integrity, and we do not see any clear path to a deployable mechanism to provide authorization checks over resources from out of region. its a broken process. it inherently permits things to be said, which should not have been said. if some strong checks can be created, and if a remote DB referential integrity issue can be resolved, I think we could discuss this. If the intention is to continue using open maintainer to add any non-RIPE resource? thats a really bad model. -George On Tue, Jul 18, 2017 at 3:25 PM, Nick Hilliard via db-wg <db-wg@ripe.net> wrote:

---------- Forwarded message ---------- From: Nick Hilliard <nick@foobar.org> To: denis walker <ripedenis@yahoo.co.uk> Cc: Database WG <db-wg@ripe.net> Bcc: Date: Tue, 18 Jul 2017 14:25:05 +0100 Subject: Re: [db-wg] out of region routing in the RIPE Database denis walker via db-wg wrote:

...

We would like to start off the (final?) round of discussions on this topic with a question. Should the RIPE Database be used as an open, free, global Internet Routing Registry (IRR)? If the answer is 'yes' then perhaps we should allow the routing policy of any global resource to be documented in the RIPE Database as a choice by the resource holder and move on to address the issues surrounding this process. If the answer is 'no' then perhaps we shouldn't allow any routing policy for any non RIPE resources (not selectively try to expel one group of ROUTE objects).

I am not in favour of having the RIPE database as an open-access database on the basis that this mixes up two sets of data, authoritative and non-authoritative, and it it is impossible for someone casually querying the database to determine which is which.

Some people are inserting random route: objects into the database, and those route: objects are being picked up by provisioning systems and ending up configured on routers and IXP route servers. This enables prefix hijacking, which is a pressing operational issue.

There are two main ways to fix this problem:

1. change all non-RIPE address space to have a different source: tag

2. remove all non-RIPE address space completely

There is some previous discussion about this issue on db-wg, and IIRC, the WG suggestion was to go for option #2.

On that basis, again IIRC, there was a suggestion to handle this in a phased way, starting off with the lowest hanging fruit first. As Afrinic objects formed the largest share of all out-of-region objects in the ripedb, they were targeted first. I believe the plan was to continue on after that with other categories of objects. This recollection may be wrong.

Nick