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. > >> >> 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. 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. For the gTLD profile there are two layers of policy, with a dependency of Response Profile (RP) on the Technical Implementation Guide (TIG), as represented by the two related extension identifiers of icann_rdap_response_profile_1 and icann_rdap_technical_implementation_guide_1. RDAP profiles define policy that can be crosscutting and have a dependency relationship between them. I don't see the RDAP profiles as being applicable here. 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. 2. The strategies need to be qualified by the applicable extension type(s) for clarity, with either the term "replacements" or the new term "superseders" consistently. 3. The strategies need to be defined as non-exhaustive, since there are other possible applicable strategies to the design of new versions of extensions. Without the non-exhaustive language, the working group will need to come to consensus that this represents the full list of possible strategies. 4. Solicit the working group for other strategies for inclusion in draft-ietf-regext-rdap-extensions. I would request for "Standalone Superseders with Versioning", where new versions of an extension are standalone with support for versioning. This is what draft-ietf-regext-rdap-versioning was designed for. 5. Remove strategy "Overlapping Replacements" in Section 5.4.3.2 unless a case can be made for inclusion. I believe the "Overlapping Replacements" strategy recommends a bad extension design, where there is a permanent inheritance relationship between two versions of an extension. In all the extensions (EPP and RDAP) I've worked on, there are no cases where there was the intent to define an inheritance dependency to a prior version (e.g., Successor EPP DNSSEC RFC 5910 is independent from the predecessor EPP DNSSEC RFC 4310). -andy, no hats _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
