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.
Section 2.3.1:
"This document updates [RFC9082] to allow the usage of extension
identifiers as path segments which may have child path segments"
What's the rationale for this proposed change? It's not a clarification.
It is specifically allowing something that is not specified in RFC 9082, and
that some extensions may want to utilize when formulating RESTful URLs.
Is there a specific issue with it?
[SAH] I’m not a fan of any change to 9082 that allows something that’s
described as a prefix to be used as something other than a prefix. It can cause
confusion. Looking at the example in the draft, absent the underscore there’s
nothing that identifies “foobar” as an extension identifier when used to create
a “foobar/fizz” path segment. Is a server supposed to guess that it might match
a “foobar_” extension? Explicit pattern matching seems safer to me.
The text of the draft says the extension identifier IS the path segment.
There is no guessing needed, I am not sure how that is confusing. If you can
provide clearer text, that would be welcomed.
Also, this is already something this working group has approved of in an
extension:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-rir-search-09#name-path-segments-2<https://secure-web.cisco.com/1VYTllhyopLiK0SITGwZM-wMbw8fOontORWuurCZYfmIW-c2sTHqGDGVS15MnQHo1QPNVy4fjqcwtW1zCMA5_OSMurzqVjT5O_oQnrs5-PZQ5kkuGzjRrcJGlRPKTbjOCCeK_MsqXHyRibcDTDm_MCSUv_CY7NYsKRjjLAfCoE7V8EoBRDVUJSWbPH3Rm3UO3dotidaocAGKw67bs4uIPRtkLITT50vtoX3YwkZgEe93fJmsweu_TkUeT5kdLoQFvMzCD9qq26s8K6l-lgb-6VMq9IaxpzDuxTKRcDIB1nPaCFkgx5FXXl9hdoLS0XgaM/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-rir-search-09%23name-path-segments-2>
[SAH] As noted in my example above, I don’t support this change so I can’t
provide text to make it clearer.
2.4.5:
"That is, the extension identifier is used "bare" and not appended with
an underscore character and subsequent names" and "Usage of a bare extension
identifier contravenes the guidance in [RFC9083]. This document updates
[RFC9083] to explicitly allow this pattern."
There are extensions that violate 9083, so we should update 9083? It
would be far more appropriate to update the extensions that violate 9083..
To be honest, I agree that this should have never happened. But this type of
violation has been committed by this working group, RFC 9537 being an example.
And while RFC 9537 has many interoperability issues, practically speaking this
isn't one of them. In practice, this does not appear to be harmful so it seems
impractical to relitigate the issue and to open up all the violating
extensions. Do you feel otherwise?
[SAH] I’d feel better about fixing the extensions than I do about changing
RDAP to legitimize them. Technical errata could be submitted to note the
violations, and the errata could be held for document updates.
The changes necessary for this cause interoperability problems and would
require obsoleting and replacing those RDAP extensions. Is that what you are
advocating for? Because that seems terribly disruptive for something that is
not a known technical issue.
[SAH] Yes, that’s what I’m advocating for. I’d rather change the
non-conforming Proposed Standard extensions than update an Internet Standard to
validate them. Updating the Proposed Standard will be far more disruptive than
updating the optional extensions.
-andy
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
