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
