On Tue, 5 Apr 2022 at 17:51, Leo Vegoda <[email protected]> wrote: > > On Mon, Apr 4, 2022 at 1:43 PM denis walker <[email protected]> wrote: > > [...] > > > > What am I missing? > > > > What you are missing is that many, many, many of these /24 allocations > > are not being used by the resource holder';s organisation. They are > > assigned to end users. > > Thanks for stating this clearly. > > I agree with everyone else that ensuring the published contact data > are accurate is most important. Does that require a software solution? > Could it be accomplished with a process change? For instance, if an > LIR leases a block to a network operator and shares some kind of > documentation with the RIPE NCC, could the RIPE NCC delegate control > of the contact data to the network operator for the duration of the > lease?
It is not only the contact details that are wrong. If an allocation is leased/rented to another LIR how should this be documented in the RIPE Database? Currently many of these blocks are being assigned to the receiving LIR. But they most likely use this address space in the same way as they use all their other allocations. It is quite possible many of these blocks are being sub-assigned by the receiving LIR. But that is not allowed with the database syntax. So the true nature and usage of this address space is unknown. Leasing address space is becoming more common now. Perhaps we need yet another status value for INETNUM objects like 'ALLOCATED-BY-LIR'. So it is possible to reflect that an allocation has been re-allocated to another LIR, who can then assign it. But of course with so many /24 allocations now we are back to the original problem of re-allocation of a whole allocation... cheers denis co-chair DB-WG > > Kind regards, > > Leo -- 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
