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] Using the RIPE Database for IPAM
- Previous message (by thread): [db-wg] Using the RIPE Database for IPAM
- Next message (by thread): [db-wg] Using the RIPE Database for IPAM
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at foobar.org
Thu Sep 15 12:54:06 CEST 2022
denis walker via db-wg wrote on 13/09/2022 14:16: > I was struggling to know exactly > what is meant by the phrase "using the RIPE Database as an IPAM > solution". the dbtf interpreted this as something along the lines of: "using the RIPE Database as the canonical reference for the holder's internal address assignments". The difficulty here is that the ripe db wasn't really designed to be granular enough, or private, or extensible enough, to suit the requirements of LIRs and other DB consumers for generic IPAM functionality. Separate to this, because it's a public database, there is no way of not exposing potentially confidential data. On the other hand, IPAM software suites are built for these purposes. Ultimately, people need to use tools that are fit for purpose. You can knock in a nail with a pliers, but that doesn't make it the best tool for hammering. Nor does it make it pliers any less useful as a type of tool. We're in the same territory here with the RIPE DB and purpose-built IPAM systems. Nick
- Previous message (by thread): [db-wg] Using the RIPE Database for IPAM
- Next message (by thread): [db-wg] Using the RIPE Database for IPAM
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]