Hi Tom, Thanks for addressing my comments.
I'm marking the document revised I-D needed, and awaiting your updates. Regards, OS, ART AD On Wed, Jan 29, 2025 at 5:09 PM Tom Harrison <t...@apnic.net> wrote: > 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` <http://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` > <http://192.0.2.0/25> is present but ` > > 192.0.2.128/25` <http://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` <http://192.0.2.0/25> is repeated in > its bottom objects, > > whereas `192.0.2.128/25` <http://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 >
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
