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/db-wg@ripe.net/
[db-wg] Control over associating objects for number blocks
- Previous message (by thread): [db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
- Next message (by thread): [db-wg] Control over associating objects for number blocks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
William Sylvester
william.sylvester at addrex.net
Tue Oct 27 14:48:09 CET 2015
Dear Database Working Group Members, At the last RIPE meeting we discussed the topic of orphaned objects, and it seems that this term was confusing to some. This is an attempt to clarify the problem and hopefully find a solution forward. This continues to be a problem where number block holders are getting “locked” out of being able to manage their routing objects and in-addr records. Today, we continue to have a problem where a block holder does not have an ability to manage the objects that operationally impact their number blocks. Examples include a routing or reverse dns object that exist in the database but are not currently maintained by an active number block maintainer. This is typically the case where a number block holder (usually legacy) may have contracted services through a third party. Time goes by, the business relationship ends but the third party never removed their associated records (in-addrs, routing objects, etc). The number block holder now seeks to update the block (either directly or through a new service provider) and is unable to add these resource records to their number block. The database can help fix this problem through allowing the appropriate control for a number block holder to maintain their own information. In many cases the last resort is to contact RIPE NCC to make the change to an object the number block holder should have had online access to manage directly in the first place. This proposal intends to enable number block holders to have a greater ability to manage their own resources. I propose that the maintainer of a number block shall have full control over the association of contacts, routing, and reverse dns entries related to the number block held. The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block. The number block maintainer shall have an ability to delete the relationship between a related object and the number block through the LIR Portal, Webupdates, and related systems. Open items to discuss; 1) What is the best method to enable a number block holder to manage and control objects associated with their blocks in Ripe DB? 2) Should any objects be excluded from this control? 3) 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/20151027/f0f37fa4/attachment.html>
- Previous message (by thread): [db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
- Next message (by thread): [db-wg] Control over associating objects for number blocks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]