From: Jasdip Singh <jasd...@arin.net> Sent: Monday, October 7, 2024 3:53 PM To: Hollenbeck, Scott <shollenb...@verisign.com>; a...@hxr.us; regext@ietf.org Subject: [EXTERNAL] Re: [regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi. Please see my comments, marked [JS]. Jasdip From: Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org> Date: Monday, October 7, 2024 at 11:42 AM To: a...@hxr.us <a...@hxr.us>, regext@ietf.org <regext@ietf.org> Subject: [regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04 From: Andrew Newton (andy) <a...@hxr.us> Sent: Monday, October 7, 2024 6:41 AM To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org Subject: [EXTERNAL] Re: [regext] Comments Regarding draft-ietf-regext-rdap-extensions-04 Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 10/3/24 10:57, Hollenbeck, Scott wrote: On 10/2/24 11:06, Hollenbeck, Scott wrote: I've read draft-ietf-regext-rdap-extensions-04 completely and have several comments to share. An overarching comment is that any update to Standard 95 responses means that the modified responses will not be consistent with "rdap_level_0". A new identifier will be needed. I'd very much prefer to avoid updates to Standard 95 unless there's an absolute necessity to do so. This draft does not change the RDAP data model and all updates are either backwards compatible and/or codify existing practices, many of them made by this working group. As there are no changes to the RDAP data model and this draft is dealing with extensions and not the core of RDAP, can you provide specific examples of these inconsistencies? [SAH] The data model might not be changing, but that's not the only consideration. Recall this sentence from Section 4.1 of RFC 9083: "The string literal "rdap_level_0" signifies conformance with this specification". It doesn't say anything about the data model. I interpret that sentence to mean that if RFC 9083 changes, "rdap_level_0" continues to signify conformance with RFC 9083, NOT with whatever updates it. Also, I'd like to point out that this working group has not updated "rdap_level_0" even when making changes to the core RDAP data model, as the move from PS to IS did in fact change the core RDAP data model but did not change the identifier. With regard to interoperability between a client and a server, what is changing that is incompatible? What core RDAP JSON or query is changing? Can you provide specific examples? This document updates the core RDAP specs for two reasons: 1) they define the rules around extension registrations, many of which this working group has repeatedly broken, and 2) there are areas of those documents concerning extensions that are very ambiguous. But this document changes nothing with regard to current interoperability between a client and server. Also, changing that identifier signals a new version of the protocol, which this is not, and introduces an incompatibility with any current software that relies on it. I don't know the extent of that incompatibility, but I suspect at the very least many conformance tools will break. [SAH] A specific example: I have a server that implements the foobar extension, RFC 7480, 9082, and 9083. It expects to receive query path segments that include "foobar_". It receives a query that includes "foobar/fizz". It doesn't recognize that path segment, so the query fails. That's protocol breakage. [JS] Servers work from an expected lookup or search path per the definitions in a supported extension. Therefore, "foobar/fizz" should be as much a valid expectation if so defined in an extension, as long as namespace collisions are prevented. That said, "foobar_a/b" would be needed for an extension if another extension already defines "a/b" for the same base path. E.g., "domains/foobar_a/b" for extension "foobar" to de-conflict from "domains/a/b" for extension "a". For an example of "domain/a/b" path for extension "a", see https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-rir-search-09#name-path-segments-2. [SAH] This is precisely why we have issues with extensions that aren't following the guidance in the core specs. Those that define their own extension identification mechanisms can cause problems. "foobar/fizz" isn't valid per the existing core specs, and should not be defined as such in an extension specification. Scott _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
