Tom, 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? If it does, the remaining question is purely editorial: whether this lives as INR-specific text in a separate document, as you suggested, or as a section in the referrals draft. I have no strong view and will go wherever the chairs think causes least confusion. All the best, Kaveh On Wed, Jul 15, 2026 06:37 AM, Tom Harrison <[email protected]> wrote: > Hi Kaveh, > > On Mon, Jul 13, 2026 at 10:30:29AM +0100, Kaveh Ranjbar wrote: > > On the authority boundary I think we are talking past each other, > > and that is my fault for not scoping it sharply. Your examples are > > all inside the registry system: an RIR serving its own direct > > delegations alongside members' records, or an RIR mirroring an NIR > > and returning the most-specific it holds. I agree completely that > > there is no boundary to expose there and no client change is > > warranted. An RIR delegates to an NIR, the NIR decides whether to > > expose user-space detail or not, and either way the answer is still > > served by a registry the bootstrap already points to. The RIR > > boundary stays the RIR boundary, and RFC 9224 longest-match does > > exactly the right thing. > > > > The draft is not about that case. It is about the resource whose > > subordinate detail is held by neither the RIR nor an NIR, but by the > > holder, on the holder's own RDAP server, > > These aren't mutually exclusive situations, though. Per earlier > comments, we at APNIC are open to redirecting to an NIR's RDAP server > for queries for that NIR's resources, if an NIR deploys such a server. > Possibly more relevantly, LACNIC already do this today with nic.br: > > $ dig +short registro.br > 200.160.2.3 > $ curl -s -L https://rdap.lacnic.net/rdap/ip/200.160.2.3 | jq > '.links[] | select(.rel == "self")' > { > "value": "https://rdap.registro.br/ip/200.160.0.0/20";, > "rel": "self", > "href": "https://rdap.registro.br/ip/200.160.0.0/20";, > "type": "application/rdap+json" > } > $ > > > which is not in the IANA bootstrap and cannot be reached by > > longest-match at all. There is no most-specific record for the > > client to land on, because the registry does not hold one, by > > design. That is a genuine crossing out of the registry system, not a > > more-specific lookup within it, and it is the only case this draft > > speaks to. > > It seems to me that this is putting too much emphasis on the specific > RDAP server that is encoded in the bootstrap file. Apart from the > fact that HTTP redirects can be used to get the client to the account > holder's server automatically, the other key consideration is that in > the normal course of things, the RDAP user is going to see the same > data regardless of whether that data is hosted by the RIR itself or by > the relevant account holder. It's not as though all RDAP-related > actions taken by an account holder in a hosted system are audited by > registry staff before being accepted. > > > Which is also why it is backwards-compatible in the way your concern > > asks for. Because these holder servers are off-bootstrap, nothing > > about existing most-specific expectations against RIR or NIR data > > changes. A client that ignores rdap-base-down is exactly as well off > > as it is today. > > The fact that an unchanged client will get the same response > post-deployment as it does pre-deployment does not alter the > backwards-compatibility concerns here. Assuming the draft were > implemented as-is, the most-specific relevant RDAP response would then > be available only to clients that had been updated to support the > draft. > > -Tom >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
