Optional RDAP referrals for subordinate resources in the RIPE Database

We already let the registry delegate reverse DNS for the space below an allocation to the holder. This proposal asks for the same move for registration data.

RDAP answers can be followed from the IANA bootstrap down to the most specific object the RIPE NCC holds, and stop there. Holders that keep registration data for more specific networks below their allocation, and publish it through a conformant RDAP service, have no discoverable referral from the RIPE response to their own server, so today they either register nothing below the allocation or bulk load objects that drift out of date.

The proposal, in four parts, all opt-in:

1. Registration of a holder RDAP base URL on the covering object, as an attribute in the spirit of geofeed:, so port 43, the REST API and RDAP all show it.
2. Once a holder has opted in, a redirect for RDAP lookups of subordinate resources to that service, so unchanged clients land on the right record.
3. An additive link in the RIPE response for clients that want to discover the delegation itself.
4. What validation the NCC would do at registration, how it keeps checking, and how a referral is withdrawn when the holder's service stops working.

The mechanics come from the IETF: the redirect and the noRedirects0 extension are now in draft-ietf-regext-rdap-referrals-05, the holder case is described in draft-ranjbar-regext-rdap-subordinate-referrals, and a live holder-side server answers today for 2a04:2a01::/32 (AS219419) at rdap.whisper.online. The aim of the slot is a sense of the room on whether to ask the RIPE NCC for an impact analysis and take this forward as a DB-WG work item, and which of the four parts the group wants changed.