[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Previous message (by thread): [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Next message (by thread): [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sebastian-Wilhelm Graf
ripe-lists at sebastian-graf.at
Thu Sep 28 11:41:16 CEST 2023
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 at foobar.org> wrote: >> denis walker wrote on 24/09/2023 17:12: >>> 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 >> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xCB3F9792B5ACD96C.asc Type: application/pgp-keys Size: 3935 bytes Desc: OpenPGP public key URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20230928/830649d3/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20230928/830649d3/attachment.sig>
- Previous message (by thread): [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Next message (by thread): [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]