Hi Job On 27/07/2016 21:43, Job Snijders wrote:
On Wed, Jul 27, 2016 at 07:32:48PM +0000, ripedenis@yahoo.co.uk wrote:
Hi Tim Can we have some up to date numbers on how many (if any):
<snip - leaving that for NCC/NIC staff>
Assuming any exist:
-How do you propose to handle any objects that have a version in both databases that are different?
Can't they just co-exist? And whoever can meet the authorisation requirements can delete either one of them.
Phase 4 in Tim's proposal is to delete these objects from the RIPE Database. I can see the benefit of deleting them as we don't want different or diverging data in these databases. But then you need to know which version is the most accurate to copy into Afrinic's database.
I think this is a question for AfriNIC to consider, not for the RIPE NCC staff.
The RIPE Database is the responsibility of the RIPE community and managed by the RIPE NCC. So if there are any different versions (and maybe there aren't) then we need to consider what to do about them.
-What do you propose to do with set objects that reference any of these objects?
What type of set objects are you specifically referring too?
Any
Generally operators use set expanders that span multiple databases. Speaking for myself in any of the networks I operate I don't see an issue whether the route objects are in RIPE or in AfriNIC's IRR. Just make sure your data source mirrors AfriNIC.
-How do you propose to handle any routing policy statements in other ASN objects that refer to any objects from this set of affected ROUTE(6) or ASN objects?
Can't those references remain? References don't need to terminate in the same database.
For both the above questions there are no referential integrity checks in the database. So syntactically there is no problem. I raised the questions so that people more knowledgeable than I on routing issues could think about them and decide if this data will still make sense (again, if any exist). You may remember there was a very controversial issue on the table at the Warsaw RIPE meeting about 'cleaning up' ASNs :) cheers denis
Kind regards,
Job