[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

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: </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: </ripe/mail/archives/address-policy-wg/attachments/20230928/830649d3/attachment.sig>