[db-wg] Using the RIPE Database for IPAM

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 at 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://mailman.ripe.net/