Comments in-line: On Thu, Mar 30, 2023 at 5:38 PM Antoin Verschuren <ietf=40antoin...@dmarc.ietf.org> wrote: > > 2. With regards to the hierarchy itself, there are 2 use cases that can be > served better: > Most common use cases are: > > -Where is address space used when querying an IP address or prefix > Usually, this is the assignment of address space, which is recorded in the > bottom of the hierarchy that whois usually presents by default. > -Who is responsible for maintaining the address space registration when > querying an IP address or prefix. > Usually this is the allocation of address space that is responsible for > administration and f.e. creating RPKI ROAs, which is the top of the hierarchy > in the INR registry. > > Instead of reiteratively querying “up’ and “down” relations until you reach > the top or bottom of the hierarchy, I want to suggest to add a “top” and > “bottom” relationship query to immediately reach those objects. Some language > should be there that Top and Bottom mean top and bottom of the hierarchy of > the specific INR, not to include f.e. imported IANA or other parent IR > allocations.
I think walking up and down the tree is bad as well, but I don't think that was the intent. At one point RIPE NCC had some terminology about "least-specific", "most-specific", "most-specific-enclosing" or something like that. And that type of language is common in IP network hierarchies. Perhaps that could be leveraged here. And while I support such queries, I think it is a fair argument to note that those are not "reverse search" queries. > > 3. We discussed that IRR objects that are often also registered in RIR > databases may be out of scope for this document as the aim for this document > is to replace most common whois queries. However, some RIRs (RIPE, APNIC) > include IRR data (f.e. route objects) by default in whois responses for IP > address space, and ASN/autnum objects returned in whois queries also contain > IRR data in the objects itself in the form of import/export statements in the > autumn object. If the aim is to replace whois queries, including RPSL > responses, than maybe we should discuss including optional query/response > definitions for AS-SET and Route Objects? > Since Tom called me out on this during the meeting... the reason IRR objects were not included in the original RDAP base was that the original mandate from the RIR perspective for RDAP was to represent the most common objects of RIRs, and at that time IRR was not common across all RIRs. It is today, but even so it is somewhat of a different beast across them. And IRRs are run by way more than just RIRs or INRs. All that said, I'm happy to revive that old IRR work if there would be active help from the RIRs, but I don't think that is part of this document. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
