[db-wg] Proposal regarding Orphaned Objects

Shane, 

Thanks for your note While the database currently allows for the managing of sub-allocations, it does not allow for managing related objects where the inetnum maintainer is not the maintainer of the attributes like routing objects and in-addr objects. This is a really big problem for older records and legacy records. In this specific case, I was hoping that much like sub-allocations we might be able to grand similar parent-child relationships to the objects where the inetnum maintainer is different from the object attribute maintainer. I have encountered this use case where the holder of a inetnum number block hired an ISP many years ago, the ISP is listed as the maintainer on the routing object. When the inetnum holder attempts to modify or delete the routing object the current system blocks this action. Even after they have gone through the “un-locking” process within RIPE. That process does not account for related objects. This is where I classified these objects as orphaned. Primarily because in many cases these are old unused routing or in-addr objects where as the holder of the inetnum you are unable to delete or manage them. You are currently forced to attempt to locate and find the maintainer of said object. In some cases this is easy and the maintainers quickly comply through deleting the object. In most cases though, the maintainer is un-reachable where you must then open a ticket with RIPE NCC. This process can often times take quite a while. A better solution would be to enable the inetnum number block holder full control over their block. This prevents situations where one of these related objects could hold the inetnum hostage because you can not make operational changes. Through enabling this it will also make it easier to keep the database accurate. 

So while you are correct that you can manage sub-allocation, this is not the case for related objects which do not share the same maintainer. 

Thanks,
Billy

> On May 1, 2015, at 5:02 AM, Shane Kerr <shane at time-travellers.org> wrote:
> 
> William,
> 
> On Tue, 28 Apr 2015 14:32:33 -0400
> William Sylvester <william.sylvester at addrex.net> wrote:
> 
>> Currently, when a number block holder wishes to update their number
>> block they are unable to do so directly. They must contact the
>> maintainer of the old object. Many of the older maintainers do not
>> have current contact or have been acquired by another company and
>> left in an unknown orphaned status. These maintainers can be
>> difficult or impossible to contact. RIPE NCC then must be engaged to
>> make the change to an object the number block holder should have had
>> online access to manage directly in the first place.
> 
> As I understand it, the database allows the maintainer of
> less-specific ("parent") inetnum or inet6num objects to delete
> more-specific ("child") objects.
> 
> So, the recipient of either an allocation or assignment from the RIPE
> NCC already has the power to clean up their space.
> 
> I believe this sort of delete functionality also applies to route and
> related domain (meaning reverse DNS) objects. 
> 
> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation-1.79/10-authorisation/10-13-reclaim-functionality-1/10-13-2-authorisation-to-reclaim
> 
> As I understand it, your proposal has already been implemented, with
> the difference that maintainers can only delete, not modify objects
> that they do not directly maintain but are in their space.
> 
> Cheers,
> 
> --
> Shane