[db-wg] NWI-3 - AFRINIC IRR Homing

Hi Denis, WG,

> On 29 Jul 2016, at 03:28, denis <ripedenis at yahoo.co.uk> wrote:
> 
> Hi Tim
> 
> On 28/07/2016 11:35, Tim Bruijnzeels wrote:
>> 
>>> On 28 Jul 2016, at 04:19, Randy Bush <randy at psg.com> wrote:
>>> 
>>>>> -How do you propose to handle any objects that have a version
>>>>> in both databases that are different?
>>>> 
>>>> I think this is a question for AfriNIC to consider, not for the
>>>> RIPE NCC staff.
>>> 
>>> you dump crap on them and tell them to clean it up.  nice.
>> 
>> I can see how it can look that way, but that was not our intent. In
>> short our intent was to 1) not risk interrupting routing, 2) give the
>> real resource holder the ability to clean up (i.e. in the Afrinic
>> IRR).
>> 
>> If the Afrinic resource holder does have access to their object in
>> the RIPE DB today, then they can delete the object before this
>> migration. But, unfortunately, in case they don't we (RIPE NCC) do
>> not have a reliable way to determine claims.
> 
> Yes you do. ROUTE(6) objects are the responsibility of the address space resource holder. This is irrespective of which RIR region they are in. Working 'with' AfriNIC it is quite easy to identify who has claim over these objects in the RIPE Database.

As you know we don't have these resource holders in the RIPE NCC registry, and the maintainers were set up with the RPSL password. That's why we have this NWI and NWI-5 (Out of region ROUTE(6) / AUT-NUM objects) in the first place.

Could you elaborate on how this is supposed to work exactly?

> We believe that it's
>> best that in these cases objects *are* copied over to the Afrinic IRR
>> in phase 3 - so that the actual resource holders can choose to keep,
>> or force delete these objects as needed.
>> 
>> The simplest way to do this is by copying all objects. I can see
>> possible smarter scenarios where duplicates are excluded on import,
>> or where Afrinic resource holders can somehow mark their resources as
>> already migrated. But to echo Job, I think this is for Afrinic and
>> their community to consider.
> 
> This simple copy process does not work if there are duplicates with different content. If Afrinic are the ones who will decide on how to handle duplicates then they need to have considered this and come to a decision on how to handle them before the start of Phase 3 of your plan. Up until that point it is still possible a duplicate ROUTE(6) object in the RIPE Database could be modified to have different content to the one in AfriNIC Database.

I agree this needs to be resolved before this phase is started but I also believe it's not my place to suggest exactly how this should work. As I said "..I think this is for Afrinic and their community to consider". If you have specific suggestions I think you are free to voice them.

> btw although you did not specify it I assume when Phase 3 is implemented you will also add a business rule to the RIPE Database to prevent any of the Afrinic ROUTE(6) objects from being modified in the RIPE Database.

correct, also the time to phase 4 was intended to be very short - we just want to be sure that remaining objects (for whatever definition in phase 3) are copied to the Afrinic IRR, before they are deleted in the RIPE Database IRR.

> As long as these points are addressed, your plan will work. But I still don't see why AfriNIC can't simply put pressure on their resource holders to 'do it themselves'.

They are. But, the reality today is that the Afrinic resource holders are still required by their peers to put ROUTE(6) objects in the RIPE Database IRR. And there is a need for phased migration.

Cheers
Tim


> cheers
> denis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20160729/444d4e88/attachment.html>