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]
