Hi Tom,
That is a lot of good information, unfortunately none of it is in the RFC.
Adding this information if/when 9910 gets revised would be a good idea, and
that is why I said this should be a Hold For Document Update and not Verified
errata.
-andy, as an individual
On 09-03-2026 5:48 PM, Tom Harrison wrote:
On Tue, Mar 03, 2026 at 12:00:59PM -0800, RFC Errata System wrote:
The following errata report has been submitted for RFC9910,
"Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR)
Search".
--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8801
--------------------------------------
Type: Technical
Reported by: Andy Newton <[email protected]>
Section: 3.2
Original Text
-------------
The relation searches defined in this document rely on the syntax
described above. Each search works in the same way for each object
class.
Corrected Text
--------------
The relation searches defined in this document rely on the syntax
described above. The search for IP addresses works as described
in the section below. The search for reverse domain names works as
the relationship between the reverse domain name and the
corresponding IP address(es) used to provision them, where that
relationship is defined in the section below. The search for
autnums is defined by server policy.
Notes
-----
Autnums have no natural hierarchy in the numbers themselves, and
therefore the search semantics for the relationships is depends on
server policy.
I don't think this is correct, but it's a complicated issue. The
short answer is that at least one RIR (APNIC) depends on the ASN space
being hierarchical within the context of a single RDAP server, and RIR
search can be implemented as written regardless of whether an RIR
treats the ASN space that it manages as hierarchical or flat. If the
space is flat, then the set of related objects (i.e. top, bottom, up,
down, parent, children) is simply empty, and ASN-related RIR searches
will return no results. This is analogous to the case of an IP object
representing a delegation from IANA where no more-specific delegations
from it have yet taken place.
The long version (some of which will be well-known, but including for
the sake of completeness):
- Abstracted from how they are used in practice at various
registries, ASNs have a hierarchy that mirrors that of IP
addresses. Both types have a number space, the concept of a range
value, and the ability for ranges to nest/overlap, and those three
things are sufficient to establish a hierarchy. Or in other words,
there is nothing fundamental about ASNs that means the delegations
can't be modelled hierarchically.
- It is fair to say that operationally, the way that IP addresses
work is dependent on their hierarchical nature (e.g.
more-specifics taking priority in BGP) in a way that isn't the case
for ASNs. However, putting aside operational use and considering
the registration context alone, the way the two number spaces
operate is basically the same (per the previous point).
- Extending the first point slightly: IANA delegates blocks of ASNs
to the RIRs, who then (for the most part) delegate individual ASNs
to account holders, so in a 'real-world' sense, there is a
delegation hierarchy.
- At APNIC (though not at the other RIRs, as best I can tell), our
RDAP and Whois servers model ASNs hierarchically. This is due in
part to our previous practice of delegating blocks of ASNs to
National Internet Registries (NIRs), who then delegate individual
ASNs out of those blocks to their own account holders. The
registration details for the block delegations as well as the
individual ASN delegations are made available via our RDAP and
Whois servers. Our RDAP server has operated in this way since
2015.
- RFC 9082 has the following
(https://www.rfc-editor.org/rfc/rfc9082.html#section-3.1.2):
Queries for information regarding Autonomous System number
registrations are of the form /autnum/XXX where XXX is an asplain
Autonomous System number [RFC5396]. In some registries,
registration of Autonomous System numbers is done on an individual
number basis, while other registries may register blocks of
Autonomous System numbers. The semantics of this query are such
that if a number falls within a range of registered blocks, the
target of the query is the block registration and that individual
number registrations are considered a block of numbers with a size
of 1.
It's reasonable to read this as implying that the ASN space is
flat, in that a given ASN is either registered as part of a range,
registered as a single number, or not registered. This is further
supported by the fact that the text on IP lookups includes specific
requirements around hierarchical behaviour (see
https://www.rfc-editor.org/rfc/rfc9082.html#section-3.1.1), and
there are no similar requirements in the corresponding ASN text.
However, the ASN text is not completely unequivocal on this point.
At least at APNIC, per the previous point, we implemented RDAP ASN
queries in the same way as for IP network queries, in that the
most-specific record in the hierarchy is returned.
- RFC 9224 does not support hierarchical behaviour for ASNs, but it
does support hierarchical behaviour for IP addresses, which might
be interpreted as providing further support for the idea of the ASN
space being flat. However, there is currently no dependence/use on
that document's support for hierarchical behaviour for IPs, and no
real prospect of it happening in the future, so it would have been
possible to omit that behaviour from the original document. In
other words, it's not clear that significant weight can be placed
on the absence of that behaviour for ASNs.
- APNIC's demo implementation of this functionality, per the RFC 7942
listing in the document
(https://www.ietf.org/archive/id/draft-ietf-regext-rdap-rir-search-19.html#name-apnic-rdap-implementation),
includes hierarchical ASN search functionality along the lines of
how it is intended to operate at APNIC when the production
implementation is done (i.e. it's not as though nobody turned their
mind to this issue when the document was in progress).
- Theoretically, APNIC could convert its RDAP server to treat the ASN
space as flat, and then there would be (in effect) no use case for
ASN search. There are several reasons not to do this, though:
- it would be a substantial change from a backwards-compatibility
standpoint;
- it would make our RDAP server less aligned with how our Whois
server operates;
- it would lead to us providing less information to clients (e.g.
if a user queries an ASN in an NIR block delegation, and the NIR
has not yet delegated that ASN, there will be nothing in-band
about the larger block delegation that was made to the NIR,
since the response will be for the single ASN only);
- the relevant text in the related specifications is not
unequivocal on this issue; and
- the NRO RDAP profile (registered with IANA) depends in part on
RDAP supporting hierarchical behaviour for ASN queries (see
https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-rdap-profile.txt,
section 6.1.2.2).
-Tom
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
