Hi Denis,

On 26 Oct 2016, at 12:30 AM, denis <ripedenis@yahoo.co.uk> wrote:

Hi Piotr

I commented some time ago about the possibility of a ROUTE object existing in both the RIPE Database and the Afrinic Database with different content. Did anyone do the simple check to see if any such objects exist? If they do, has anyone thought about who's responsibility it is to decide how to handle them?

I am not aware of any actual check having been done yet. However, anecdotally and based on some of my own experience, I strongly believe that: - there are likely to be some. - the number will however be very small. I am therefore of the opinion that for those that do exist, AFRINIC and RIPE staff can work together to resolve them without that being too much of a burden for either set of staff. I’ll add that as the AFRINIC IRR is (relative to others) a young DB, if an object exists in it - any one of unique, exact duplicate or inconsistent content (your concern) - then AFRINIC will very very likely have a valid and working contact. Using this together with simple checks like where are the resources actually originating in global BGP should allow these to be resolved. I personally don’t believe this will prove to be a big deal.

Has anyone considered what to do with AUT-NUM objects that reference the Afrinic ROUTE objects after they are deleted?

Well, as route(6) objects where the IP resources are AFRINIC, but the AUT-NUM is RIPE are out of scope for the NWI. As such, can I safely assume you’re talking about where the ASN resource is allocated or assigned by AFRINIC to an member in our region, and the RIPE DB AUT-NUM object was used to set up a ROUTE(6) object also in the RIPE DB. In that case, once the ROUTE(6) object is moved, by definition of there being a ROUTE(6) object in the AFRINIC IRR, there’d have to be an equivalent AUT-NUM in the AFRINIC DB too. As such, I don’t see any need to keep the AUT-NUM in the RIPE DB, and would expect it to be cleaned up and removed. My understanding is that the resource holder’s resource(s) are in another region, likewise (at that point) the related route(6) objects. And so the holder should have no expectation of an AUT-NUM record to exist in RIPE DB, as it serves no purpose and does not relate to RIPE NCC resources. Best regards, Daniel