Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Andrew Newton <[e-mail]>]

Thanks Tom. Looks good to me.

-andy

On Thu, Jan 25, 2024 at 10:28 PM Tom Harrison <[e-mail]> wrote:
>
> Hi Andy,
>
> Thanks for your feedback.
>
> On Thu, Dec 07, 2023 at 02:55:21PM -0500, Andy Newton wrote:
> > 1. The elidation in figure 2 (section 3.4) should be pointed out. At
> > first I mistook the hrefs as some sort of relative URLs.
>
> These have been updated to use concrete URLs now.
>
> > 2. It would be helpful if section 4 noted that the object instances
> > returned in the arrays are defined in RFC 9083. IMHO, the beginning
> > words of "As with RFC 9083" don't make that clear.
>
> This has been updated.
>
> > 3. Perhaps this is beyond the scope of the draft, but is the intent to
> > have the links for up/down/bottom/top be placed in responses for IP
> > and autumn lookups as well?
>
> Yep, that's right.  The intent here is that each object will include
> at most one link for each type of relation, and each link will be
> relative to the object itself, per the example in section 3.4.  (It's
> not mandatory that these links be included in all objects, either.)
>
> > And using the example tree in figure 1, if a search of
> > /ips/rirSearch1/up/192.0.2.0/25 returns 192.0.2.0/24, would that
> > returned object then have all the child and bottom links in that
> > tree?
>
> It would have a single child link and a single bottom link.  The child
> link href would resolve to a search that returned 192.0.2.0/25 and
> 192.0.2.128/25, while the bottom link href would resolve to a search
> that returned 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32,
> 192.0.2.128/26, and 192.0.2.192/26.
>
> > 4. It took me some time to figure out the purpose of the rirSearch1
> > extension identifier (it's because of /domains in RFC 9083).
>
> That's true.  It's also present in order to facilitate future updates
> (by incrementing the number at the end of the identifier).
>
> > Considering this document registers 5 extension identifiers, this
> > draft presents the use case for allowing IETF extensions to forgo
> > the need of using identifier prefixes if there is a good reason.
> > That said, have you considered registering one extension identifier
> > and using a prefix because "rirSearch1" appears in all paths and
> > ruins the aesthetic symmetry with 9083 anyway? Something like "rs1"
> > for RIR Search 1 and then paths of /rs1_autnums/..., /rs1_ips/...,
> > and /rs1_domains/...
>
> The paths for the basic searches do not include rirSearch1, which
> means that their forms are consistent with those from 9082/9083.  On
> the more general question: if we rely on a single identifier only,
> then that means that the reverse search definitions end up with
> "searchable resource type" values like "rs1_ips" and "rs1_autnums".
> Apart from being confusing, given the reverse search document's
> definition of corresponding unprefixed "related resource type" values
> and use of unprefixed "searchable resource type" values for the other
> object classes, it also means that the search definitions would need
> to be updated whenever a new version of the RIR search document was
> completed.  Although using multiple identifiers comes with its own
> costs, we think the benefits outweigh those costs here.
>
> -Tom