This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Proposal regarding Orphaned Objects
- Previous message (by thread): [db-wg] Database release 1.79.1 deployed to RC environment
- Next message (by thread): [db-wg] RIPE 70 DB-WG agenda V2
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
William Sylvester
william.sylvester at addrex.net
Tue Apr 28 20:32:33 CEST 2015
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 at addrex.net <mailto:william.sylvester at addrex.net> -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/db-wg/attachments/20150428/55616fe2/attachment.html>
- Previous message (by thread): [db-wg] Database release 1.79.1 deployed to RC environment
- Next message (by thread): [db-wg] RIPE 70 DB-WG agenda V2
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]