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(a)ripe.net> wrote:
>
>
> ---------- Forwarded message ----------
> From: Nick Hilliard <nick(a)foobar.org>
> To: denis walker <ripedenis(a)yahoo.co.uk>
> Cc: Database WG <db-wg(a)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
>
>
