[regext] Re: Review of draft-ietf-regext-rdap-extensions-14

[Andy Newton <[e-mail]>]

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