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]
