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