Colleagues

This has been discussed many times with many views expressed. We are sure lots of you are bored with commenting on this issue. Unfortunately no consensus has yet been found. So we would like to take it back to the basic question and see if we can get a conclusive answer. This is not a question specifically about the Afrinic homing project. It's a more general question about the RIPE Database providing this 'feature'. Even if you have commented before, please do so once more so we can get a definitive answer to this question. I know there is a tendency to say nothing if someone else has made the point you support. But this time we do need numbers. So even if what you are thinking has been said, please at least add a +1 so we know you also agree with that point.

Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources?

We see three most likely answers to this question. Each possible answer does have consequences.

A: Yes the RIPE Database should allow creation of ROUTE objects for non RIPE resources. If this is the answer then we can look at how to make the data more trusting in the short term (and there may be ways to do that).

B: No the RIPE Database should not allow creation of ROUTE objects for any non RIPE resource. If this is the answer then maybe we need to look at a project to remove all non RIPE resource related ROUTE(6)/AUT-NUM objects from the RIPE Database and disable the feature. But that needs to look at what to do with ROUTE objects for prefixes from one region and ASNs from a different region.

C: Just leave things as they are. Don't promote the service but no projects to remove any data from the RIPE Database either. Just drift along on the principle "if it ain't broken, don't fix it". This also means document this as the answer to this question and no more discussions. Of course any problems associated with this feature don't go away.


I will briefly review the discussions over the last 2 years:

At the update given at RIPE 72 for the removal of the data starting with the Afinic homing project, there was no consensus and a call for more comments on the mailing list. A discussion continued on the mailing list until October. There was both support and opposition to removing these objects from the RIPE Database. One point raised during this discussion regarding the Afrinic homing project was, "I believe that what is needed here most of all is a clear message from both communities that it is desirable to have the ROUTE(6) objects for AFRINIC space in the AFRINIC IRR where the registered resource holders can properly authorise objects." No one has yet referred to a declared consensus of opinion by the Afrinic community to the removal of these objects from the RIPE Database. Also during this discussion Afrinic said that they have not yet worked out all the fine details of the proposed move of this data. Several issues were raised on the technicalities of moving this data and it was said in the discussion that no one has yet even done the analysis to see if any of these conditions exist (like duplicate, but different data in both databases).

At the update given at RIPE 73, there was still no consensus. The RIPE NCC and Afrinic were asked to do a check on what could go wrong and who members could contact in the event of things going wrong. This doesn't seem to have been done. The RIPE NCC suggested they may be able to produce a video or webinar about the transfer. This doesn't seem to have been done either. The call was again made that both the RIPE and Afrinic communities re-state that they both want this project to go forward. That has not happened. It was said that Afrinic is the first of many RIRs that may want data transferred out of the RIPE Database. Is it the RIRs or the communities that want this? The only question raised in the meeting was opposed to the transfer. No discussion followed on the mailing list.

At RIPE 74 there was no update on this issue.

The next discussion wasn't until July 2017. In this discussion there was mention of developing a global IRR database with a couple of supporters. We all know such ideas often take years to be agreed on, designed and implemented as a practical solution. We want to answer this question in relation to the situation today. There were some pointers made back to previous mailing list discussions, but nothing else new was said.

cheers
denis
co-chair DB WG