On 24-03-2026 2:43 AM, Tom Harrison wrote:
Some IP address registries have a problem that is closer to the
registry-registrar problem in the domain name space, in that there are
delegated address registries that host their own information about the
relevant resources, but users might also be interested in the
information that the RIR has directly. At least for APNIC, those
delegated registries are national internet registries (NIRs). The way
we handle this problem is by using the redirect_with_content
extension. (This extension may not be a good fit for the domain name
use case, because the scenarios are not 1:1, but noting here in case
it might be helpful.)
IMO, this is better handled by a link referral in RDAP. Yes, you can send an entity body
in a redirect but a lot of clients will not process it. Maybe there needs to be a
specific RDAP relation for this, such as "rdap-delegated".
An example of a redirect request from a domain registry to a domain
registrar:
Client Request:
GET /redirects0_ref/related/domain/example.com HTTP/1.1
James Mitchell had an earlier comment on this point:
The registrar example is given as domain/link[rel=related]. I
assume the use of the related relation is defined in ICANN's RDAP
profile; it might be best to be explicit.
It looks like there has been an attempt to address this, but I think
it needs to be clearer, in order to avoid any potential confusion.
Suggested (not sure where it should be put, but anyway):
The "related" link relation does not of itself indicate that the
associated link is for a registrar resource. There are profiles
that ascribe this behaviour to that link relation, though: see
e.g. [gtld-rdap-profile]. Clients should ensure that link
relation interpretations take into account the original link
relation definition, as well as any adjustments or refinements to
that definition that have occurred by way of extension
implementation.
Is this the right doc to clear up what "related" means?
(Though having said that, I can't find the part of the gTLD profile
that requires this behaviour with respect to "related" links. Would
you be able to point me to that?)
It is 3.2 of the TIG:
https://itp.cdn.icann.org/en/files/registry-operators/rdap-technical-implementation-guide-21feb24-en.pdf
The redirect query for the parent network of 192.0.2.42 with the
base URL of https://rdap.example.net/ would be:
https://rdap.exampple.net/redirects0_ref/rdap-up/ip/192.0.2.42
RIR search already defines URLs for this, so while it might be
possible to use this specification in this way, I think it would be
better either to limit the examples to link relations that do not have
alternatives (like "related"), or to note that while the RIR search
link relation types are usable in the redirects0_ref context, clients
would be better off using the existing RIR search URLs directly. (A
concrete reason for preferring those URLs over the redirects0_ref
example above is that RIR search links are an optional element in RDAP
responses, and a server implementor may return 404s for such referral
queries even when the underlying search is supported by way of the
original RIR search URL.)
My client currently knows how to follow links based on relationships. Adding in
"rdap-up", etc... was just a matter of repurposing the link following code,
whereas reformulating very specific URL paths is entirely new code. From a client
perspective, there is a benefit for doing this.
If an RDAP server holds in its datastore more than one relationship
type for an object, a scenario that is possible but not common, only
one of the URLs, as determined by server policy, can be returned.
I don't think this behaviour is a good idea. For a link relation type
like "related" (outside of the gTLD RDAP profile context), it's easy
to imagine there being multiple links having that type, and that new
links might be added/removed at arbitrary points in time. That would
lead to inconsistent results even within the context of a single
server. I think it would be better to say that servers implementing
this document must either:
- include in the response at most one link with a given relation
type; or
- return 400 (or similar) where a referral request is submitted and
the relevant object has two or more links with the specified type.
Except the request is not malformed. A 409 is probably a better candidate.
5. Bootstrap Use Case
A bootstrap link could be useful in some cases, but it's not clear to
me how it would be useful in the referral context. A client that
knows ahead of time that it wants bootstrap information should either
use the RFC 9224 process directly, or send its queries to a known
bootstrap server.
6. Multi-Hop Redirect Limitations
In some scenarios, a target server might have a policy to issue
another redirect using this extension. For example:
Client Request to rir1.example:
GET /redirects0_ref/rdap-top/ip/2001%3adb8%3a%3a1 HTTP/1.1
Accept: application/rdap+json"
Server Response:
HTTP/1.1 307 Temporary Redirect
Location: https://rir2.example/redirects0_ref/rdap-top/ip/2001%3adb8%3a%3a/32
I think the better reading of the RIR search document is that it does
not support responding to requests in this way. See e.g. section
3.2.1: 'The "parent' object is the next-least-specific object that
exists *in the relevant registry*".
Ok. We can create an example relationship type for demonstration purposes
instead of using rdap-top.
That said, does RIR Search not provide a way to express a relationship between
a resource transferred into one RIR from another? If I have a /24 at LACNIC
that was transferred from ARIN, when querying the LACNIC server is there no way
to find my way back to the parent allocation at ARIN? If not, this seems like a
miss in RIR Search. (and that is exactly a scenario I had 2 weeks ago)
-andy, no hats
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
