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] IRRd re-write
- Previous message (by thread): [db-wg] IRRd re-write
- Next message (by thread): [db-wg] IRRd re-write
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
denis walker
ripedenis at yahoo.co.uk
Tue Jun 19 15:58:15 CEST 2018
Colleagues My suggestion about the IRR(s) yesterday didn't seem to go down too well, so I will try again. I will start with a question. Why do people believe that having many, many independent/commercial IRRs, mostly containing unverified operational data and lots of personal data, where they all have to be mirrored to access the full data set is preferable to having multiple instances of a single data set containing fully verified and trusted operational data and no personal data? I agree it is always good to re-write old, unmanageable code. But without a cross registry authorisation link to all 5 RIRs number registries, the new IRRd is the same product. The data in all these third party IRRs using the new IRRd is still unverified. You are correct Job that I have zero experience of operating networks or generating anything to do with BGP. My understanding is that is what you do using the data you take out of an IRR database. I am only thinking about the structure and management of a public database containing high quality, trusted data for global resources, not what you do with that data. This is something I do have decades of experience of. cheers denis co-chair DB-WG -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/db-wg/attachments/20180619/99ff70a7/attachment.html>
- Previous message (by thread): [db-wg] IRRd re-write
- Next message (by thread): [db-wg] IRRd re-write
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]