Hi, I created a bunch of issues in github on what I believe we discussed:
https://github.com/gbxyz/draft-ietf-regext-rdap-referrals/issues All that said, I am fine with rdap-base-down/up but I think we need something that can point directly to the resource. If we are saying that rdap-up/down/top/bottom are that direct pointer, my understanding was that those relationships are not expected to cross authoritative boundaries. And I am fine with those relationships staying that way, but we would need a new one. rdap-base-down/up contain the "rdap-base" which, as used with other RDAP terminology, means a URL that the client must process to obtain the full RDAP URL, as opposed to simply dereferencing the URL. My apologies if I am confused or have caused confusion. -andy, no hats On Fri, Jul 17, 2026 at 2:47 PM Kaveh Ranjbar <[email protected]> wrote: > > Tom, Andy, Jasdip, > > Thank you, all three of you. That was exactly the review I was hoping for, > and it has left the draft in a much better place than it started. > > To capture where we landed so that -01 reflects it: the server MUST still > redirect for transport, so an unchanged client continues to receive the > most-specific record with no change on its side; it MAY additionally > advertise rdap-base-down on the covering object, so a client that cares can > discover the delegation and cross the authority boundary deliberately; and a > no_redirects flag lets a client ask for the registry's own record alongside > the child's. I will take Jasdip's rdap-base-down / rdap-base-up split, so > direction is explicit at the point of use and RFC 9910's rdap-up stays > exactly as it is. Scope stays narrow: the holder-run server below the > covering allocation, off the bootstrap, and not the in-system RIR and NIR > cases, which need none of this. > > On where it lives, I have no strong preference and would rather follow the > chairs: either a section in the referrals draft, or a small INR-specific > document defining rdap-base-down/up and the no-redirect flag. Happy to go > whichever way causes least confusion, and glad to pick it up in Vienna. > > I will fold all of this into -01 once the submission tool reopens. > > All the best, > Kaveh > > On Thu, Jul 16, 2026 02:41 AM, Tom Harrison <[email protected]> wrote: >> >> Hi Kaveh, >> >> On Wed, Jul 15, 2026 at 05:29:38PM +0100, Kaveh Ranjbar wrote: >> > I think one word has been doing too much work in this exchange, and >> > your LACNIC example is what made it clear to me, so thank you for >> > it. >> > >> > I have not been proposing the relation in place of the redirect. I >> > have been proposing it on top of one. The registry still redirects >> > for transport, so an unchanged client asking for the more specific >> > resource lands on the holder's record exactly as it does today. That >> > is the whole of your backwards compatibility concern, and I want to >> > meet it head on: the most specific answer stays reachable with no >> > client change. rdap-base-down is not the path to that answer, it is >> > a second, optional thing on the covering object that says a >> > subordinate service exists and lets a client that cares enumerate >> > and cross the boundary deliberately. no_redirects is the third >> > piece, for a client that wants the registry's own record as well as >> > the child's. Redirect for compatibility, relation for discovery, >> > flag for the parent. Not one instead of another. >> > >> > On registro.br, I read that as the in-system case rather than a >> > counter to it. registro.br is a registry, and LACNIC redirects to it >> > because LACNIC has been configured to: the pointer lives in the >> > system and the bootstrap-plus-redirect chain reaches it. That is >> > exactly the RIR and NIR situation I agreed needs no new machinery. >> > The case the draft is scoped to is narrower: a holder running RDAP >> > for delegations below its own allocation, records the RIR keeps out >> > of its database by design, on a server no one has configured the RIR >> > to point at. Where the holder does register that pointer with the >> > registry, I am happy for the server to redirect, and to say so with >> > a MUST, which I think is the requirement you asked for earlier. What >> > the relation adds in that case is only what the bare redirect cannot >> > give: that a delegation exists at all, and that answering it crossed >> > out of the registry's own data. >> > >> > So I think we are closer than the last few mails suggest. If I write >> > -01 as "the server MUST still redirect, and MAY additionally >> > advertise rdap-base-down, with no_redirects available to a client >> > that wants both records," does that resolve the compatibility >> > objection for you? >> >> Yep, that sounds fine to me, thanks. >> >> -Tom _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
