Hi Job, all, > On 11 Jan 2018, at 02:27, Job Snijders <j...@instituut.net> wrote: > > On Thu, Jan 11, 2018 at 01:17:09AM +0000, denis walker wrote: >> Unless it has been modified recently there is the reclaim >> functionality that will allow the resource holder to delete the >> ROUTE(6) object >> https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-holders >> But this does rely on the new resource holder knowing the 'potentially >> rogue' ROUTE(6) object exists. So maybe it is down to a procedural or >> administrative issue around the transfer process. > > Good pointer, perhaps the issue is resolved if "towards RIPE NCC"-migrations > are procedurally forced to go through the 'reclaim' process for ROUTE(6) > objects, to ensure no objects exist that the (new) owner didn't approve > of?
The ROUTE(6) objects are not always kept. In my understanding this is a case by case decision, based on the dialogue we have with involved parties during the transfer. Usually they are deleted, but if the parties wish to keep the ROUTE objects we can. This applies only really to the transfer of live networks, which are rare. They will then be moved from “RIPE” to “RIPE-NONAUTH” or vice versa. ROUTE(6) objects moved into “RIPE” space can be reclaimed as Denis pointed out. For objects moving out of the RIPE region there will be no reclaim available (except by RIPE NCC), so in this case it’s important to verify that the recipient has, or will have, their MAINTAINER added to the object. Of course it would also be good form to add the recipient’s MAINTAINER for a transfer into or inside of the RIPE region - the reclaim will work, but will also leave a window where no object(s) exist until they are recreated and this could lead to outages in case a live network is transferred. As I mentioned these cases are rare, and they are dealt with on a case by case basis. We could formalise the process more I suppose, but I believe that so-far we have always been able to find an agreeable solution with all parties involved. Kind regards, Tim > > Kind regards, > > Job >
