This is a great draft, and I'm glad that this work is going forward. I do have a few comments.
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. 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. 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? 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? 4. It took me some time to figure out the purpose of the rirSearch1 extension identifier (it's because of /domains in RFC 9083). 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/... -andy On Mon, Nov 27, 2023 at 9:51 AM Antoin Verschuren <ietf=40antoin...@dmarc.ietf.org> wrote: > > The document editors have indicated that the following document is ready for > submission to the IESG to be considered for publication as a Proposed > Standard: > > > RDAP RIR Search > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/ > > > Please indicate your support or no objection for the publication of this > document by replying to this message on list (a simple “+1” is sufficient). > > If any working group member has questions regarding the publication of this > document please respond on the list with your concerns by close of business > everywhere, Monday, 11 December 2023. > > If there are no objections the document will be submitted to the IESG. > > The Document Shepherd for this document is Mario Loffredo. > > Thanks, > > Jim and Antoin > REGEXT WG Co-Chairs > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
