On 8/11/26 12:24 PM, Gould, James wrote: > > The gTLD RDAP profile did this. > > JG-I don't see the gTLD RDAP profile as an example of the “Non-overlapping > Replacements” strategy, since I was directly involved in the RDAP Profile > Tiger Team led by Rick Wilhelm. There was no consideration to backward > compatibility with the predecessor RDAP profile (version 2.1) > (icann_rdap_technical_implementation_guide_0 and > icann_rdap_response_profile_0) and of the successor RDAP profile (version > 2.2) (icann_rdap_technical_implementation_guide_1 and > icann_rdap_response_profile_1) and certainly there was no desire to maintain > the functionality of the predecessor. I view the gTLD RDAP profiles as being > mutually exclusive policies. They can't be supported at the same time; > servers needed to do a hard cutover. The "Default Version with Client > Override" transition consideration in draft-ietf-regext-rdap-versioning could > have been used by introducing support for RDAP profile version 2.2 an opt-in > and then switching the default to RDAP version 2.2 with support for > requesting RDAP version 2.1 during the transition period.
There were server operators who listed both versions of the RDAP profile during the transition period, and the text of the 2024 version did not forbid the use of the 2019 version. Even today the profile's text does not forbid it. It is only forbidden by the instructions given by ICANN which are not part of the extension. BTW, nothing bad happened. Clients just continued on working. > >> >> Section 5.4.3.2 “Overlapping Replacements” >> >> >> >> I don’t support this consideration for the extension authors, since >> extension replacements can have overlapping structures, but defining an >> inheritance hierarchy between extension replacements does not allow for the >> extension replacements to stand on their own. This will add a permanent >> inheritance dependency between RDAP extensions that should be avoided. > > As stated, a superseder is indistinguishable from a new, unrelated extension. > This is STD95. > It is allowed today, and I don't see why we would not allow it. > > JG-I'm not stating that it should not be allowed, but that I consider it a > bad RDAP extension design choice that should be avoided. I'm requesting that > draft-ietf-regext-rdap-extensions include the term "non-exhaustive" for the > strategies so that other strategies, including the transition considerations > included in Section 7 of draft-ietf-regext-rdap-versioning, are also allowed. > > > If an extension author wants to go down this path, that is their choice. It > is certainly much easier to do this to add a single field than to introduce > the machinery of another method, such as the migrating to the versioning > draft. > > JG-I have seen no attempts to support the concept of extension inheritance in > RDAP with " Overlapping Replacements", so I'm not exactly sure where the > "Overlapping Replacements" strategy is coming from and what operational > experience there is with it for inclusion in > draft-ietf-regext-rdap-extensions. Do you have a reference to the use of > this strategy or an example of where it would be used in the future? Take a look at the NRO profile and its use of overlaps with cidr0 and the asn flat and hierarchical models. -andy, no hats _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
