Hi Orie, Thanks for your review, much appreciated.
On Tue, Jan 28, 2025 at 05:15:49PM -0600, Orie wrote: > # Orie Steele, ART AD, comments for draft-ietf-regext-rdap-rir-search-13 > CC @OR13 > > * line numbers: > - > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-rdap-rir-search-13.txt&submitcheck=True > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > ## Discuss > > ### 200 or 404 > > ``` > 715 If the search can be processed by the server, but there are no > 716 results for the search, then the server returns an HTTP 200 (OK) > 717 [RFC9110] response code, with the body of the response containing an > 718 empty results array. > ``` > > https://www.rfc-editor.org/rfc/rfc7480.html#section-5.3 implies that a 404 > MUST be returned. Thanks, we will update this part of the document to note that a 404 should be returned in this case. > ### Bare identifiers > > The shepherd writeup comments on the use of "bare identifiers", and I > recall some discussion regarding possible collisions. > > I didn't see anything about this in security considerations, are there some > "valid but harmful" examples that we can share to warn implementers, or has > this issue been resolved? There was some discussion about the risk of collision when bare identifiers are used as path segments under existing path segments, as is the case here with '/domains/rirSearch1/<relation>/<domain name>' (the '/domains' path is defined in RFC 9082, https://www.rfc-editor.org/rfc/rfc9082.html#section-3.2.1). See https://mailarchive.ietf.org/arch/msg/regext/YtvMiv3xoNnxqBomm5lyTqrEgqo/ from Scott Hollenbeck: Please note that the domain relation search function described in the draft is apparently extending the core "domains" search described in RFC 9082. Both currently use "domains" in the path segment. That isn't optimal. There is no collision with the "ip" and "autnum" path segments from 9082 because those values are singular. This draft uses the plural forms "ips" and "autnums". If there's some reason that the above is invalid, please explain why. The "rirSearch1" identifier appears in path segments and the rdapConformance data structure, but I don't see how it actually identifies an extension element unless it's intended to disambiguate the "domains" search collision I noted above. If that's the case, use of the extension prefix to create "rs_domains" would avoid the collision entirely. and https://mailarchive.ietf.org/arch/msg/regext/nHfJg1hA0h5RcEDzn0M3WQ63on4/ (also from Scott), where it was noted that there is no collision problem in this instance, because '/domains' queries per RFC 9082 can be unambiguously distinguished from '/domains/rirSearch1' queries per this draft. Additionally, from https://mailarchive.ietf.org/arch/msg/regext/X5vlp8Il8WVg8S0bouV8mKz_UXk/ (also from Scott): Mario, my concern about a possible collision arose because “domains” (from RFC 9082) === “domains” (from the draft). I’m not sure if the draft is specifying a new “domains” path segment (in which case the names do collide), or if the draft is extending the 9082 path segment by adding additional elements to the path. My confusion exists because the draft isn’t using prefixed extension identifiers. The situation would be unambiguous if the draft used something like “rs_domains”, or “domains/rs_rirSearch1”. The prefix is a clear indicator of what’s being extended. In my exchange with Jasdip I did note that there’s no operational issue here even if there is a collision because a properly formed query will contain other information that enables a server to correctly process both 9082 queries and RIR search queries, though I’d prefer that the information included an extension identifier prefix. To summarise, there isn't a collision problem in this document itself, so we don't think that any text about that is needed here, though it may be a good idea to add something about that to the extensions document (https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/). On the related topic of bare identifiers, https://www.rfc-editor.org/rfc/rfc9082.html#section-5 has: Custom path segments can be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F). For example, a custom entity path segment could be created by prefixing "entity" with "custom_", producing "custom_entity". and https://www.rfc-editor.org/rfc/rfc9083.html#section-2.1 has: Servers that insert such unspecified members into JSON responses SHOULD have member names prefixed with a short identifier followed by an underscore followed by a meaningful name. both of which run counter to the concept of bare identifiers. https://mailarchive.ietf.org/arch/msg/regext/9ZJ8P51rEIJs0jw0OnPIH0cnPGI/ sets out the authors' reasons for using bare identifiers notwithstanding the text in RFC 9082 and RFC 9083 on this topic. > ## Comments > > ### Better Search Example Syntax? > > Instead of: > > ``` > 157 ips?handle=XXXX > ``` > > Consider syntax like: > > ``` > Client request: > > GET .well-known/api-catalog HTTP/1.1 > Host: example.com > Accept: application/linkset+json > > > Server response: > > HTTP/1.1 200 OK > Date: Mon, 01 Jun 2023 00:00:01 GMT > Server: Apache-Coyote/1.1 > Content-Type: application/linkset+json; > profile="THIS-RFC-URL" > > { > "linkset": [ > { > .... > ``` > > (borrowed from - > https://datatracker.ietf.org/doc/draft-ietf-httpapi-api-catalog/08/) We would prefer to use the existing syntax, for consistency with the searches defined in RFC 9082. > ### Top/Bottom > > Is there a reason that `192.0.2.128/25` is missing from: > > ``` > 391 +==================+===========================================+ > 392 | INR object value | Bottom objects | > 393 +==================+===========================================+ > 394 | 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, | > 395 | | 192.0.2.128/26, 192.0.2.192/26 | > 396 +------------------+-------------------------------------------+ > 397 | 192.0.2.0/25 | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32 | > 398 +------------------+-------------------------------------------+ > 399 | 192.0.2.128/25 | 192.0.2.128/26, 192.0.2.192/26 | > 400 +------------------+-------------------------------------------+ > ``` > > I expected to see text explaining why `192.0.2.0/25` is present but ` > 192.0.2.128/25` is not. The set of bottom objects comprises the most-specific objects that entirely cover the specified object value. '192.0.2.0/25' is present as a bottom object for '192.0.2.0/24' because it is the most-specific object in the hierarchy for the addresses in '192.0.2.0/25', save for those addresses that fall within '192.0.2.0/28' and '192.0.2.0/32' (i.e. it's fine for the set of bottom objects to overlap, if that's what's required to cover the specified object value). '192.0.2.128/25' is not present as a bottom object for '192.0.2.0/24' because it is itself completely covered by more specific objects, being '192.0.2.128/26' and '192.0.2.192/26'. > I also wonder why `192.0.2.0/25` is repeated in its bottom objects, > whereas `192.0.2.128/25` is not. The answer here is similar to the previous one. '192.0.2.0/25' is not completely covered by more-specific objects, so it is included in its set of bottom objects. Whereas '192.0.2.128/25' is completely covered by more-specific objects, so it is omitted from its set of bottom objects. > ### SHOULD return 501? > > ``` > 505 By default, any valid status value may be used for status filtering. > 506 Server operators MAY opt not to support "status" filtering for the > 507 "down" and "bottom" link relations, in which case the server should > 508 respond with an HTTP 501 (Not Implemented) [RFC9110] response code if > 509 it receives such a request. Server operators MAY also opt not to > ``` Thanks, we will update this to SHOULD. -Tom _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
