<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dear Database Working Group Members, <div class=""> <br class="">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. </div><div class=""><br class=""></div><div class="">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.<br class=""><br class="">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. <br class=""></div><div class=""> </div><div class="">Open items to discuss; </div><div class=""><br class=""></div><div class="">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? </div><div class=""><br class=""></div><div class="">2) What objects should be included? Should any be excluded? </div><div class=""><br class=""></div><div class="">3) What is the right hierarchy for the objects? </div><div class=""><br class=""></div><div class="">4) What is a reasonable schedule for announcements and implementation? </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thank you for your consideration and I look forward to your comments. </div><div class=""><br class=""></div><div class="">Billy</div><div class=""><br class=""></div><div class="">William Sylvester</div><div class=""><a href="mailto:william.sylvester@addrex.net" class="">william.sylvester@addrex.net</a> </div><div class=""><br class=""></div></body></html>