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] Proposal regarding Orphaned Objects
- Previous message (by thread): [db-wg] Proposal regarding Orphaned Objects
- Next message (by thread): [db-wg] Proposal regarding Orphaned Objects
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Shane Kerr
shane at time-travellers.org
Fri May 1 21:07:00 CEST 2015
Billy, On Fri, 1 May 2015 11:15:52 -0400 William Sylvester <william.sylvester at addrex.net> wrote: > In my use cases, the holder of the inetnum is the ultimate authority > for a number block and associated routing. It’s possible that due to > historical reasons there is a lot of older data that needs cleaning > up. I know for example locked ‘status: LEGACY’ objects typically have > high proof of holder-ship required. Once this is done, a holder is > able to have their object un-locked. These associated objects are not > always included in this process. Should they be? Is there a case > where an inetnum holder should not be able to dis-associate in-addr > or routing objects from their inetnum? I sympathize with your problem, and actually tend to agree with your philosophy here. Why should we treat legacy networks differently from non-legacy networks? Making it difficult to clean up related objects just results in crap in the database, and may have actual operational impact (inability to peer, incorrect reverse DNS, and so on). So I think we should accept your proposal, which then becomes, "apply reclaim functionality using all inetnum objects". Thanks for sticking through the discussion! :) Cheers, -- Shane
- Previous message (by thread): [db-wg] Proposal regarding Orphaned Objects
- Next message (by thread): [db-wg] Proposal regarding Orphaned Objects
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]