--- Begin Message ---
On 18/07/2017, 15:26, Nick Hilliard via db-wg typed:
>
>
> 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.
Hello WG,
That matches my recollection too.
And so I'll re-iterate that, as previously mentioned on this list, this neatly
matches up with some parallel goals within AFRINIC. Which is that regardless,
we see an advantage in having our membership manage their IRR along with RDNS
and RPKI and other registry interactions in one place under one authentication.
Simpler. And we also see an advantage in general growth in usage of the AFRINIC
IRR by our membership, as it's a service we already provide and will maintain
and scale as needed in any case.
And so, we do already provide tooling to our membership to assist them moving
objects into the AFRINIC DB easily. We do liaise with upstream operators of our
members when they have in the past implied a requirement for RIPE DB IRR
objects. And our hostmasters also do run bootcamp tutorials at nog and other
events to encourage migration of objects.
In summary there is ongoing work that matches with migrating non-RIPE, AFRINIC
route(6) objects underway. I will add that this is a long and slow process
however. The work is done as convenient. And for now, only applies where both
the IPv{4,6} an AS resources are within the AFRINIC region.
The movement is slow. But in the direction of moving AFRINIC resources away
from RIPE DB.
Regards,
Daniel
--- End Message ---
