Andy, My responses are embedded below prefixed with "JG2-".
-- 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/12/26, 4:52 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/12/26 1:27 PM, Gould, James wrote: > Andy, > > My responses are embedded below prefixed with "JG-". > > -- JG James Gould Fellow Engineer [email protected] > <mailto:[email protected]> > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] > <mailto:[email protected]>> 703-948-3271 12061 Bluemont Way Reston, VA > 20190 Verisign.com > <http://secure-web.cisco.com/1TNl4WtQAlfihwIahY8B-i6MWh6lzHBYvwsKQUQeZ-GaOBL0MY-SlS0VCdvHY7UJwH0d9kIqt4-HzNp9qcJcRJeX3C3_1tpqQgFyuh2drK0B4XH9y5vFVx-Ed9XcV6a2Aee6N0bFP6oc7ew3IsL_0GNQ_4QrUIsywAVr2nVQCI505V0BFfXDOOJ9Px0Y5VYnA4K9-rgTidlnbhblnvviX9a5AGooLMLQCZRHCzlOMO5JsNkgNrxhDj7Jx-zoOaMEesLQo0Y1MF9TOagZucdt0iH5ePLdit1bK75t9crRHwR4OO2ikW0-XxS8sHGCJrQWt/http%3A%2F%2Fverisigninc.com%2F> > > <http://secure-web.cisco.com/1TNl4WtQAlfihwIahY8B-i6MWh6lzHBYvwsKQUQeZ-GaOBL0MY-SlS0VCdvHY7UJwH0d9kIqt4-HzNp9qcJcRJeX3C3_1tpqQgFyuh2drK0B4XH9y5vFVx-Ed9XcV6a2Aee6N0bFP6oc7ew3IsL_0GNQ_4QrUIsywAVr2nVQCI505V0BFfXDOOJ9Px0Y5VYnA4K9-rgTidlnbhblnvviX9a5AGooLMLQCZRHCzlOMO5JsNkgNrxhDj7Jx-zoOaMEesLQo0Y1MF9TOagZucdt0iH5ePLdit1bK75t9crRHwR4OO2ikW0-XxS8sHGCJrQWt/http%3A%2F%2Fverisigninc.com%2F>> > On 8/11/26, 3:09 PM, "Andy Newton" <[email protected] <mailto:[email protected]> > <mailto:[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. JG2-I don't see policy RDAP extensions as "superseder" extensions and inclusion of two profile extensions that are mutually exclusive in the rdapConformance is incorrect since you can't support the two policies in parallel. The confusion of what is and what is not considered a "superseder" needs to be addressed. The gTLD RDAP profile update did not consider overlapping or non-overlapping in the design of the policy, but what you're referring to here is how implementations chose to deploy the policies. The gTLD RDAP profile update applying to either " Overlapping Replacements" or "Non-overlapping Replacements" strategies, since they define a policy and not an extension. 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. JG2-So if clients don't use the rdapConformance as a signal for what extensions are included in the response, I question its purpose. If the rdapConformance array didn't change behavior that just means that clients are more resilient than we've discussed (e.g., breaking and non-breaking changes) or there hasn't been enough change that matters to the client. > 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://secure-web.cisco.com/1GOWsPFI15hQthgX-Cb7ZydT0YwGxHNI9A5gM6wV1I-8bUBz5J8fYP5dn5pEc2F8i-lf8pR0wfpIP7PFKsZKEQysLiCvroFvzl5JY4jpChzHJsbbNSEoLv-vo8sIfYc1x3PMwLyPl-sRjDV7L7FANZk7haY3GoT5YP8sNlO1ykdEeop-qPL-MJGk-cVqHPFccsXlaBNQ6GPZfU7yzZWvsul5yCimwOkoLne8gjuhiTsXHKvQx4LfCy13yIL-t9xi9ueekRjfu4it3ODMui8TtS4yyc0i-QBVqbTSv-GsHu8Yqv6kakzcGp-fYysg6Np0k/https%3A%2F%2Frdap.arin.net%2Fregistry%2Fhelp <https://secure-web.cisco.com/1GOWsPFI15hQthgX-Cb7ZydT0YwGxHNI9A5gM6wV1I-8bUBz5J8fYP5dn5pEc2F8i-lf8pR0wfpIP7PFKsZKEQysLiCvroFvzl5JY4jpChzHJsbbNSEoLv-vo8sIfYc1x3PMwLyPl-sRjDV7L7FANZk7haY3GoT5YP8sNlO1ykdEeop-qPL-MJGk-cVqHPFccsXlaBNQ6GPZfU7yzZWvsul5yCimwOkoLne8gjuhiTsXHKvQx4LfCy13yIL-t9xi9ueekRjfu4it3ODMui8TtS4yyc0i-QBVqbTSv-GsHu8Yqv6kakzcGp-fYysg6Np0k/https%3A%2F%2Frdap.arin.net%2Fregistry%2Fhelp> ... "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. JG2-I'm not exactly sure what you're attempting to show here. Inclusion of multiple extension identifiers in the rdapConformance indicates what has been deployed and is not a design element of defining replacement (superseder) extensions. The NTO profile defines the profile extensions with dependencies and doesn't fall into the superseder category, and I attested to the gTLD profile changes did not consider backward compatibility to the predecessor profile extension version. The strategies in draft-ietf-regext-rdap-extensions are associated with design and not deployment, where there are no examples in production where either the overlapping or non-overlapping replacement strategies have been used. The profile extensions are crosscutting and don't follow the rules defined in the draft-ietf-regext-rdap-extensions Section 5.4.3. Please consider the set of requests made for draft-ietf-regext-rdap-extensions in my prior message and respond to the mailing list with your answers to each one of them to ensure that they are fully addressed. -andy, no hats _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
