Hello James, Given the feedback during the regext session in Prague, we’ll proceed with your suggestion of registering 2 additional extension id’s – “ips” and “autnums” – beside “rir_search”.
Thanks, Jasdip From: "Gould, James" <jgo...@verisign.com> Date: Thursday, November 9, 2023 at 3:35 PM To: Jasdip Singh <jasd...@arin.net>, "t...@apnic.net" <t...@apnic.net>, "regext@ietf.org" <regext@ietf.org> Subject: Re: Re: draft-ietf-regext-rdap-rir-search Feedback Jasdip & Tom, After the IETF-118 REGEXT meeting, I found this message that I never replied to. I believe that draft-ietf-regext-rdap-rir-search needs to fully follow the extension identifier as a prefix rule defined in RFC 7480, RFC 9082, and RFC 9083. I don’t support the concept of two classes of extensions (IETF and non-IETF), as defined in section 6 of draft-newton-regext-rdap-extensions. IETF extensions must not receive an exception to the rules defined in the RDAP RFCs (RFC 7480, RFC 9082, and RFC 9083), but instead must lead by example and fully follow the rules. If use of “ips” and “autnums” is the intent, then go with the second option that I provided: Define an identifier for “ips” and an identifier for “autnums”, which would be represented independently in the rdapConformance. There is no requirement to include the “_suffix”, so this will result in optimal path segment values (“ips” and “autnums”) and provides for separation by object. It looks like you may need a 3rd identifier with rir_search, as defined in section 3.2 of draft-ietf-regext-rdap-rir-search, if you decide not to go with a single extension identifier prefix such as “rir” that prefixes all of the extension path segments. I’ll leave the makeup of the extension identifiers and the path segments up to you, but the draft needs to follow the extension identifier as a prefix rule defined in RFC 7480, RFC 9082, and RFC 9083. Thanks, -- JG [cid:image001.png@01DA1618.85891270] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Jasdip Singh <jasd...@arin.net> Date: Saturday, August 12, 2023 at 11:16 PM To: James Gould <jgo...@verisign.com>, "t...@apnic.net" <t...@apnic.net>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: draft-ietf-regext-rdap-rir-search Feedback Thanks for your feedback, James. And, sorry for the late reply. As for point #2, Section 6 gives the rationale for choosing “ips” over “<extension id>_ips” (and similarly, “autnums” over ““<extension id>_autnums”) for these new search path segments: “Because IP network objects and autonomous system number objects are part of the original set of object types defined for use in RDAP, it may be unintuitive or confusing for users if the basic searches and associated responses defined here include the "rir_search" extension prefix, since the searches and associated responses for the other original object types do not include a prefix.” Agreed that this would be an exception to the prefix rule but from the RIRs’ perspective, a reasonable one. If there is sufficient WG support for this exception for these new basic searches, perhaps we could clarify it in the “RDAP Extensions” draft [1]. Look forward to feedback from others. Jasdip [1] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/<https://secure-web.cisco.com/1NRtG_49pj2crOuDGQB7y3IHiYar59eysyVRPeBiqqImCCKV08v_Zhx2BWgtKHoWgzzy5UFuDUjoSxitfCFin4Hotr-KiTSIS7VqR3NLEDmwI3TneX53e07EEbd02AjS-xdPkvvJNJINtX3vLSiFGxHX2kFJldVqBkmaqsbRi2uRt_uTsyBe-VTxCCa837ksUk7zGfI7EcBtHaXfwsVpMDvBuIkFtLUd8AQcnO4VoCd98ilBnzycPFBBtNulvGSlAbzcXaSt7hkoQJgMJRA2EaRt_fwnMJZWy_CwYiu4xhYA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-extensions%2F> From: "Gould, James" <jgo...@verisign.com> Date: Tuesday, July 25, 2023 at 2:53 PM To: "t...@apnic.net" <t...@apnic.net>, Jasdip Singh <jasd...@arin.net>, "regext@ietf.org" <regext@ietf.org> Subject: draft-ietf-regext-rdap-rir-search Feedback Tom & Jasdip, Ahead of the REGEXT meeting this afternoon, I did a review of draft-ietf-regext-rdap-rir-search and below is my feedback: 1. I believe that the search for ips and autnums should have been included in RFC 9082 from the start, but I’m glad that you’re looking at add support in this draft. 2. My biggest issue is the extension identifier and the lack of using it in the path segments (“ips” and “autnums”) * First, I want to say that I don’t see that the use of “ips” and “autonums” will cause any confusion or conflict, but I can’t see getting past the normative language defined in the base RFCs. Section 6 “RDAP Conformance” attempts to get around the normative language, but I don’t believe it will address the requirement. I see two options for this: i. Use a shorter extension identifier as a prefix for the new path segments, such as “rir” with the path segments “rir_ips” and “rir_autnums” * This would result in a single entry in the rdapComformance element for the draft but will require the use of the non-optimal path segments. You could stick with the “rir_search” identifier, but that will make the path segments even worse with “rir_search_ips” and “rir_search_autonums”. ii. Define an identifier for “ips” and an identifier for “autnums”, which would be represented independently in the rdapConformance. * There is no requirement to include the “_suffix”, so this will result in optimal path segment values (“ips” and “autnums”) and provides for separation by object. * The use of “rir_search” may still be needed or something like it for the relation search defined in section 3.1 “Path Segments”. You could leverage the first option above with the prefix “rir” and the suffix “_search” to perform the relation search. The second option adds some complexity to support a crosscutting search function like “rir_search”, where you could use “ips_search” and “autnums_search” values or do without them since “ips” and “autnums” are registered identifiers. The “rir_search” under the domain path segment is more of an issue that needs to be considered, potentially by adding a third identifier (“rir”) to support it. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/1hbozoN0nC5vOKxQnxRdPjDgJsEG1I6wTFCyba_FNAl5kuV0pnawn_6I-g9PgtkKYj7bsZpsYXISnilpMn6bsdxVLB8qmcOAjX2ocLhp7Y0tMDVJDd7NtYxeNfQxx9ThhLNnDrPQtHZb0ybUGLz1oaDoJfd1sIWlC5InIvuXzOUgtCmjYAvN754eBAnyZ3QltrCCzFfs8seg8LGSxeR1iXTXPlsMkY2DHs3Xt1Wqmh1FFrfkRtB1rcosWTh9SkSeGRVdPXPN78uCFI34_y2uQX7v012pcAFvsiaq59B82-Ng/http%3A%2F%2Fverisigninc.com%2F>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
