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]
