Thanks Tom, I reviewed and looks good. As to the IRR queries: Fair enough to me to have them in a separate document. It was just a suggestion.
Regards, Antoin (no hat) > Op 2 mei 2023, om 01:17 heeft Tom Harrison <t...@apnic.net> het volgende > geschreven: > > Hi Antoin, > > On Thu, Mar 30, 2023 at 10:37:54AM +0200, Antoin Verschuren wrote: >> I have read this draft, and have some comments/requests as discussed >> during our IETF 116 meeting session. >> Most of my remarks are about section 4, Link Relations: >> >> 1. Suggest to replace “operator” with “server operator” to clarify >> the RDAP terminology of a client-server relation in this document. >> Especially in the last paragraph of section 4 this will prevent >> confusion that the normative language applies to the server >> operator, as the client has no notion of where in the hierarchy he >> is when making a query. > > Thanks, this has now been updated. > >> 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. > > There are now extra link relations for these cases. "top" and > "bottom" return the objects at the top and bottom of the hierarchy > regardless of whether they are "actual" delegations or not. For > finding the "top" delegation that is an actual delegation to an > account holder at an RIR, there is an additional link relation called > "top-active", indicating that the object is the top object with a > status of "active". (The separate RDAP profile for RIRs requires that > such delegations have a status of "active": see > https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-rdap-profile.txt.) > >> 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? > > We agree with Andy's comments here generally, so we think that if this > work happens, it would be better done as a separate document. > > -Tom _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
