Dear Database Working Group Members, There are many old records that have become orphaned. Examples of orphaned objects might include a routing or reverse dns object that exist in the database but are not currently maintained by an active maintainer. Many of these records have not been updated in a very long time. This proposal intends to enable number block holders to have a greater ability to manage their own resources. 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. I propose that the maintainer of a number block shall have full control over the contacts, routing, and reverse dns entries related to the number block held. In the event an object currently has a maintainer different than the holder of the number block the maintainer of the number block will be provided an upper maintainer status with rights to manage or delete associated blocks. The number block maintainer will have an ability to delete a related object through the LIR Portal, Webupdates, and related systems. At the inception of this policy the database should be updated to identify objects without a maintainer chain to the number block holder. Any identified objects should have the maintainer of the number block added as an upper maintainer to the related blocks. When a maintainer is removed from the number block, this maintainer should also be removed as an upper maintainer of the object this should work in a similar fashion when a maintainer is added to the number block. The upper maintainer will have an ability to remove the relationship between a number block and associated contacts, routing, and reverse dns objects. Open items to discuss; 1) What is the best mechanism to enable the association of existing objects and does it make sense to have the inetnum object be the central object? 2) What objects should be included? Should any be excluded? 3) What is the right hierarchy for the objects? 4) What is a reasonable schedule for announcements and implementation? Thank you for your consideration and I look forward to your comments. Billy William Sylvester william.sylvester@addrex.net <mailto:william.sylvester@addrex.net>
William, On Tue, 28 Apr 2015 14:32:33 -0400 William Sylvester <william.sylvester@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-datab... 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
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@time-travellers.org> wrote:
William,
On Tue, 28 Apr 2015 14:32:33 -0400 William Sylvester <william.sylvester@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-datab...
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
participants (2)
-
Shane Kerr -
William Sylvester