Hi Leo, Good to hear from you, and a fair challenge. You are right that for many holders IPAM-to-RIPE synchronisation is the right answer, and nothing in this proposal takes that path away. The referral is for the cases where sync stops working well, and I think those cases are becoming more common: 1. Update rate. Our assignments are created and retired programmatically, some of them living minutes. Syncing that into the central database means a high-frequency stream of writes for objects that may be gone before the next consumer ever reads them, and there is always a staleness window between what the IPAM knows and what the database serves. A referral serves the live answer at read time instead of pushing state at write time. 2. Community cost. Every synced assignment is an object the NCC stores, indexes and serves for everyone. AGGREGATED-BY-LIR exists precisely because the community preferred not to carry every assignment centrally. The referral keeps that lean default and adds only a pointer to where the detail lives. 3. Expressiveness. The holder's RDAP can carry per-assignment detail that does not map cleanly onto inetnum attributes (richer entities, operational metadata, extensions). Central sync caps the published data at what the central schema can express. On the cost point, I agree nobody should build infrastructure just for this. A holder operating at this scale already runs the authoritative source, and an RDAP view over an IPAM is a thin read-only front end. Once regext standardises the redirect I would expect IPAM products to grow it as a feature, rather than each holder building something bespoke. And because it is opt-in on both sides, holders for whom sync is cheaper simply keep syncing; nothing is taken away from them. So: sync where it fits, referral where the data moves faster than sync can follow. The proposal only adds the second option. All the best, Kaveh On Mon, Jul 06, 2026 11:21 AM, Leo Vegoda <leo@vegoda.org> wrote:
Hi Kaveh,
On 6 Jul 2026, at 11:12, Kaveh Ranjbar via db-wg <db-wg@ripe.net> wrote:
[…]
The real prize, I think, is registration data hygiene. A holder with a lot of assignment activity has two poor options today. Register nothing below the allocation, which leaves coarse, unhelpful data for abuse handling, research and routing. Or bulk-load large numbers of assignment objects that start drifting out of date the day they land, which means stale data and central database bloat. An optional referral to the place where the data is actually maintained gives the community accurate, current, granular registration data served from the source, keeps the central database lean, and preserves an unbroken, machine-walkable chain from the bootstrap to the exact object. It rewards holders for publishing good, live data rather than penalising them for it.
It sounds like a great idea but I don’t understand this part.
Why would a resource holder not prefer to have their IPAM synchronise what it knows to be true with the RIPE Database instead of spending money on building and maintaining some infrastructure? Yes, I’m assuming that anyone who wants to run their own RDAP server has an IPAM of some kind.
Thanks,
Leo