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 ]
Job Snijders
job at instituut.net
Fri May 1 21:34:43 CEST 2015
Hi, On Fri, May 01, 2015 at 07:07:00PM +0000, Shane Kerr wrote: > On Fri, 1 May 2015 11:15:52 -0400 William <william.sylvester at addrex.net> wrote: > > > In my use cases, the holder of the inetnum is the ultimate authority In any use case I can imagine the inetnum should be the ultimate authority, it comes as a suprise to me this is not the case for some types of space. The entire security model flows from there. > 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". I agree with the above. It would be much appreciated if anyone offer insight in how this came to be and why we should consider it anything else then an undocumented inconsistency (or should I just say 'bug')? Kind regards, Job
- 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 ]