Dear Denis! I strongly disagree on this notion of derferring everything to the "higher power" of RIPE. If we want a solution that integrates with IPAM Systems, then we (the community) should organise that, preferably systems that are "open" by design/license. And if only a minority of the community wishes for such a solution, then only said minority should fund that development. Especially if the benefit is mostly towards external commercial organisations.... I also reject the notion that just because the "tooling" is there (theoretically), that the accuracy would improve. But that is a disucssion further up in this thread. And personally i think aggregated-by-lir makes a ton of sense. cheers On 9/28/23 10:50, denis walker wrote:
Hi Nick
I feel your pain on this one. I can understand that no LIR wants to invest time or money in developing this as a one off, in-house solution. Something like this needs to be done at a higher level. That's why you pay fees to the RIPE NCC. They should be talking to the developers of the commercial IPAM systems about syncing with the RIPE Database. Whether or not it could be done with the current data model and software I don't know. But it is time to consider these things.
cheers denis co-chair DB-WG
On Wed, 27 Sept 2023 at 22:57, Nick Hilliard <nick@foobar.org> wrote:
So are you saying that in 2023 we can't manage a distributed database without overwhelming repetitive tasks? yes, correct. People are stuck using the tools that they have. Most off-the-shelf tools don't implement server-client or 2way database synchronisation between the local ipam system and the ripe db, and
denis walker wrote on 24/09/2023 17:12: there's ~zero financial inventive to build this sort of functionality in-house. The outcome is that the ripedb ends up with manual updates, or else with low quality / 1-way synchronisation with little or no cleanup.
The result of this is that the ASSIGNED-PA objects in the ripedb are generally of low average accuracy.
Nick