Pawel, thank you, and you have the shape right: a holder that serves registration data for resources subordinate to a registry object, names below a registered domain, or more-specifics below an allocation, from its own conformant RDAP server, whether that holder is a public sub-registry or a private one.
On the step you flag as tricky, I think it is actually the point the design turns on, so let me be precise. The referral is not attached to a query for bar.foo.example; it is attached to foo.example, the object the .example registry does hold. A client that wants bar.foo.example walks to the most specific object the registry answers, foo.example, reads the rdap-base link there, and follows it down to the holder's server, which serves bar.foo.example and links back up to foo.example with an "up" link (for a domain object; "rdap-up" for number resources). So the registry returning 404 for bar.foo.example is expected and off the path: the chain is parent object, then rdap-base referral, then holder, and it never depends on the registry answering for a name it does not hold. That is what keeps it loop-safe and lets both ends stay authoritative for what they actually maintain. On IANA bootstrap we agree, and it is why the referral exists. RFC 9224 stops at the TLD, and IANA will not carry a second-level entry, so bootstrapping down is not available. This is exactly where rdap-base is complementary to the rdap-bootstrap relation in the referrals draft: bootstrap points to what can be derived from IANA, and rdap-base points to a downstream service that by construction cannot be, because the subordinate data it serves is not in the bootstrap. The one genuinely open piece is your last one: how the registry comes to hold the holder's referral URL in the first place. That is a provisioning question, and I have deliberately kept it separate from the discovery semantics in the draft. It could be an EPP extension, a registration-time attribute, or an out-of-band arrangement; in the running code it is provisioned programmatically. I think the WG can settle the discovery relation first and treat provisioning as its own layer, and I would value your and DENIC's view on which provisioning path is realistic for a name registry. Kaveh On Thu, Jul 09, 2026 03:54 PM, Pawel Kowalik <kowalik= [email protected]> wrote: > Hi Kaveh, > > if I get the concept right it is about running a registry below TLD (on > 3rd or 4th level) - no matter if it is an open public registry or a > private one. > > The RDAP concept is probably solvable with this or other solution - here > draft-ietf-regext-rdap-referrals keeps this possibility open to chain > the redirects if it is known that the intermediate server supports the > extension. > > The tricky part is imho a step before - in a simple registry-registrar > model both parties have the object, so for both parties the resource > foo.example exists and can generate a response. > Neither registry nor registrar know however a resource bar.foo.example. > A query to .example registry will return 404 on bar.foo.example lookup > query and the chain would break. > > Theoretically IANA bootstrap rfc9224 would allow also bootstrapping 2-nd > level because of the longest entry match rule, but if I read it right > there is no way IANA will take such entry not being a top level TLD. > > Finally provisioning such an next level RDAP server reference would need > either a dedicated solution or out-of-band approach. > > Kind Regards, > Pawel > > On 06.07.26 18:14, Kaveh Ranjbar wrote: > > Dear regext colleagues, > > > > I have just submitted > > draft-ranjbar-regext-rdap-subordinate-referrals-00 and want to > > introduce it briefly and honestly: it is written as input to > > draft-ietf-regext-rdap-referrals, and I would rather see its substance > > merged there than progress it independently. > > > > The gap, in one paragraph: an RDAP walk from the IANA bootstrap ends > > at the most specific object the registry operator's database holds, > > the registered domain at a name registry or registrar, the covering > > allocation or aggregated assignment at an RIR. Holders increasingly > > maintain accurate, fast-changing registration data for resources > > subordinate to those objects (names below a registered domain, > > more-specifics below an allocation) and can serve it from conformant > > RDAP servers of their own, but there is no discoverable referral > > pointing down. The last hop has to be known out of band, which is > > exactly what RDAP was designed to avoid. > > > > The proposal is an optional, holder-designated referral, scoped > > strictly to resources subordinate to the referring object, opt-in for > > servers and clients alike, and loop-safe via an up link from the > > holder's server back to the parent object. A dedicated registered > > relation, for example "rdap-resource-holder", may be the cleanest > > carrier; the -00 deliberately defers that choice to the working group. > > I raised the number-resource half of this on the RIPE db-wg list this > > morning and the discussion there is active. My interest is better > > registry operations across both families: accurate data served from > > where it is actually maintained, lean central databases, and a chain > > that can be walked end to end. > > > > Running code exists: a holder-side server in production serves > > per-name and per-address objects for programmatically provisioned > > subordinate resources and already publishes the up link to the parent > > registry object; the registry-side referral is the missing hop. I am > > happy to demo the full walk to anyone interested. > > > > I will follow the session via Meetecho and welcome all feedback, with > > a special welcome for feedback of the form "this belongs in the > > referrals draft as section X." > > > > All the best, > > Kaveh Ranjbar > > > > _______________________________________________ > > regext mailing list -- [email protected] > > To unsubscribe send an email to [email protected] >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
