[regext] Re: AD Evaluation: draft-ietf-regext-rdap-rir-search-13

[Orie Steele <[e-mail]>]

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 <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>