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
