Hi Shane Thanks for adding some more detail. I was struggling to know exactly what is meant by the phrase "using the RIPE Database as an IPAM solution". Googling for IPAM solution, I found many systems that provide lots of features that are clearly not available through the RIPE Database. I know the RIPE NCC has this overriding principle not to provide services that compete with members or other commercial services. Is it a question of where you draw the line on what features you can build into the database software? Geofeed is an interesting example of this. There are many commercial organisations that provide geolocation information. The argument given for building geolocation details into the RIPE Database is that resource holders have a better understanding of where addresses are actually located. So having this feature in the database provides more accurate data. But has this redrawn the line on geolocation services? Is there an argument that if resource holders must use the RIPE Database for some aspects of resource registration, it makes sense to add 'some' more features to the database to make the management of their address space easier? As for privacy, let's see how the discussion goes and what people want, then see if there are any privacy concerns. I know we have also had a principle that ALL data in the RIPE Database is public. We again moved that line when we stopped making password hashes public. If the community wanted to add some additional information to the database for any purpose, there is no reason why that information would need to be public. Private data could be allowed and accessed through the LIR portal. We do need more input from resource holders on this issue. cheers denis co-chair DB-WG On Tue, 13 Sept 2022 at 09:49, Shane Kerr via db-wg <db-wg@ripe.net> wrote:
Denis,
On 12/09/2022 16.12, denis walker via db-wg wrote:
Do you use the RIPE Database as your IPAM solution? If so, read on....
Thanks for bringing this up!
This was an area that the RIPE Database Requirements Task Force always felt uncertain of. The quotes from me in your mail are correct, and I'd like to say a little more. Full disclosure: I'm speaking as one of the vice chairs of the former task force, but I am not speaking on behalf of the task force. The company I work for, NS1, provides a home for the NetBox (the open source software) and could be considered an IPAM provider. I am also not speaking on behalf of NS1, or for anyone but myself.
Apologies for the length of this message.
----
One issue is that we (the task force) never defined what we mean by IPAM. Our surveys needed to cover several points and we wanted to keep them as short as we reasonably could; surveys ask people for their time, and we need to be respectful of that. We surely could have done better, but as you (Denis) pointed out the portion of people that replied that they use the RIPE Database for IPAM surprised us.
----
Using the RIPE Database to record certain information about number resources is a requirement of obtaining those resources. RIPE NCC members and other resource holders have to learn the RIPE Database and RIPE NCC systems, and if they want certain automation have to integrate them into their processes.
Since organizations are forced to make this investment, it makes sense that they would want to use this system for as much of their IPAM needs as possible. This does not mean that all other things being equal that organizations would necessarily choose to use the RIPE Database as an IPAM solution.
If organizations want to track their addresses very closely then the RIPE Database will be unsuitable as it currently is, because it is public. For any such organization, ideally they would only have to update information in one place and have it reflected everywhere appropriate.
----
The RIPE NCC is a non-profit member-based corporation, and as such has always been cautious about providing services. This includes:
- Services that compete with members' businesses. - Services that compete with any for-profit businesses.
As an example, the RIPE NCC used to provide secondary DNS services, and was encouraged by the RIPE community to stop this except in certain narrowly-defined cases. There are companies that provide such secondary DNS services: both non-profit and for profit, both in the RIPE service region and beyond. Having a service subsidized by a monopoly competing directly with commercial interests could be considered unfair.
The RIPE NCC has felt free to provide services necessary to its function or that only it can provide, as well as experimental services that do not compete with anyone because the service literally does not exist anywhere else. So, the RIPE Database, reverse DNS, RPKI, RIPE Atlas, and so on, all fit the model and hopefully do not concern anyone.
----
I do not think that the situation about people using the RIPE Database for a certain amount of IPAM will change, because of the policy requirements. So the question then becomes, "What should the IPAM support of the RIPE Database look like?"
My own feeling is that the RIPE Database already has a RESTful API which should meet most automation needs:
https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API
I do not think there are RIPE NCC-provided tools that many IPAM solutions have, like:
- Programs which will scan a network to discover/validate devices - Tools that directly aid network planning - Tools for growth and capacity planning - Cost estimation and deployment model comparisons
I haven't looked though!
I do not know what the situation looks like for someone who wants this sort of functionality from a 3rd party software and wants it to integrate with the RIPE Database. Learning about that smells like market research, which I actually do think that it would be okay to ask the RIPE NCC to do if nobody in the community knows already.
For resource holders who are happy to only use the RIPE Database but do not want their or their users' details public, adding non-public information to the RIPE Database seems like a possible way forward. As someone who has worried a lot about privacy you (Denis) probably have more to say about the implications of that than I do.
----
Thanks again for bringing this topic up, Denis!
Cheers,
-- Shane --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg