Thanks Tom. Looks good to me. -andy
On Thu, Jan 25, 2024 at 10:28 PM Tom Harrison <t...@apnic.net> 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
