On 8/12/26 1:27 PM, Gould, James wrote: > Andy, > > My responses are embedded below prefixed with "JG-". > > -- JG James Gould Fellow Engineer [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com > <http://verisigninc.com/> On 8/11/26, 3:09 PM, "Andy Newton" <[email protected] > <mailto:[email protected]>> wrote: 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 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. > > JG-The server operators shouldn't have listed both profile versions in the > RDAP profile since they are mutually exclusive. My guess is that the clients > simply keyed off the later RDAP profile, were not impacted by the profile > transition, or didn't see it worth complaining.
Regardless, you said you don't see it as an example of non-overlapping superseder but then you said, as the author of the extension, that they weren't suppose to overlap. Your claim appears to be countering whatever point you are attempting to make. As a side note, keying off of the ext ids in the rdapConformance array is more of a protocol designers desire and not based in reality. I've now implemented 9 extensions in my client, not including the profiles, and not once did I use the rdapConformance array to change behavior. This is one of those things where people in this working group keep saying things without a basis. > Take a look at the NRO profile and its use of overlaps with cidr0 and the asn > flat and hierarchical models. > > JG-I view the dependency relationship with the NRO profile registrations, > being asn flat -> cidr0 and asn hierarchical -> cidr0 as a dependency like > all extensions to rdap_level_0. cidr0 is about IP addresses, not ASNs. > > Is the intent of Section 5.4.3.1 " Non-overlapping Replacements" and Section > 5.4.3.2 " Overlapping Replacements" of draft-ietf-regext-rdap-extensions to > apply to profile extensions defined in Section 2.1.1 or non-profile > extensions that change their extension identifier (e.g., replacements or > superseders)? I viewed them as applying to non-profile extensions that are > part of the design of a new version of an extension, so the gTLD profile and > NTO profile registrations are non-applicable operational experience. There > are many approaches to designing a new version of an extension and > implementing the transition of versions by the server. Below is a list of > requests for draft-ietf-regext-rdap-extension: > > 1. The strategies need to be defined as considerations, since there is no > operational experience for them. $ curl -H "accept: application/rdap+json" https://rdap.arin.net/registry/help ... "rdapConformance" : [ "nro_rdap_profile_0", "rdap_level_0", "cidr0", "nro_rdap_profile_asn_flat_0", "arin_originas0", "rirSearch1", "ips", "ipSearchResults", "autnums", "autnumSearchResults", "reverse_search" ], ... Again, no basis for the claim. -andy, no hats _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
