Andy, My responses are embedded below prefixed with "JG-".
Thanks, -- 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/10/26, 5:24 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. Hi James, I have incorporated most of this, so I'll just touch on a few things in this response. You can see the changes in the PR here: https://github.com/anewton1998/draft-regext-rdap-extensions/pull/87 <https://github.com/anewton1998/draft-regext-rdap-extensions/pull/87> On 8/5/26 4:30 PM, Gould, James wrote: > > I don’t recommend mirroring the “harshMistressNotes” with the “In space,”, > “nobody can hear you scream” example from RFC 9083 in > draft-ietf-regext-rdap-extensions, even though I believe it’s a reference to > the book “The Moon is a Harsh Mistress”. I recommend neutralizing the example > in draft-ietf-regext-rdap-extensions. Replicating the RFC 9083 is not needed > and providing the required use of the “rdapConformance” could be provided > alone with a neutralized example: Yes, it was a reference to Heinlein's book _The Moon is a Harsh Mistress_. That was part of the "lunarNIC" theme. Anyway, I have changed it... including the reference to screaming. JG-Great, thanks. > Nit – I recommend naming the Section 2.1.1 extension identifiers for clarity, I left the section named "Profile Extensions" as that is what is about. However, I've made the cross-references state they are about profiles in prose with a parenthetical link. JG-Thanks, that sounds good. > OLD > > > > …extensions may rely on other extensions by stipulating the usage of those > other extensions. > > > > NEW > > > > …extensions may rely on other extensions by stipulating the usage of those > other extensions. Dependencies between extensions MUST be defined using a > normative reference in the dependent extension and SHOULD include an explicit > description of the dependency. I changed the second SHOULD to a MUST unless we want to rationalize a reason for not doing it (SHOULD's are not simple choices). JG-I'm good with the MUST. > Section 5.4 “Extension Versioning” > > > > I like the formal definition of the terms “revision” and “replacement”. This > helps a great deal in clarifying the guidance. Keep in mind we changed "replacement" to "superseder" as it does not always take the place of the predecessor. JG-Replacement is easier to say than superseder, but I'm good either way. I just want to ensure that term doesn't get confused with the term "successor". > > > > The last paragraph references a 2011 blog post, MNOT-VERSIONING. This could > be perceived as a normative reference. As far as I can tell, the guidance > from the post was never included in an RFC, so I recommend removing the > reference entirely, to reduce confusion. It is an informative reference, but I've made that clearer in the markdown source. Some of MNOT's guidance did get distilled into Section 4.16 of BCP56. There was also pretty good discussion on the list about MNOT-VERSIONING, so I feel there needs to be more of a reason to remove this text. JG-The discussion is based on the lack of consensus around the [MNOT-VERSIONING] principles. Section 4.16 of BCP56 only provides examples and no direct guidance. My main concern is the weight that the informative reference is being used in the draft, with the language "Versioning of RDAP extensions is expected to follow the general principles described in [MNOT-VERSIONING]", which makes it sound normative with "is expected to follow" even though there is no BCP 14 terms used. > The extensions draft should provide guidance based on RDAP extension > definition experience and operational experience. I agree with > “Backwards-compatible changes should be favored over incompatible ones.”, but > I don’t believe that “Newer versions of extensions are not to break existing > clients” is realistic based on the progression of RDAP extensions in the > working group. If that is important, they can use the "draft" prefix to their extension identifier. JG-I don't support inclusion of unrealistic “Newer versions of extensions are not to break existing clients” based on the experience that we've had with the progression of RDAP extensions. Adding "draft" as a prefix to the extension identifier doesn't counter the language "Newer versions of extensions are not to break existing clients", since the language is unqualified. > This would also require protocol designers to reliably predict what client > implementers will do, which is not possible. If the protocol designers have no experience with implementations, that is a problem all by itself. Also, they should be able to use the list in Section 5.4.1. JG-I agree that its good for protocol designers to have implementation experience, but there is no way for the protocol designers to possibly know the details of "all" the client implementations. > * Changes to the extension interface should be transparent to the client by > changing of the extension identifier (replacement above), use of a versioning > extension such as draft-ietf-regext-rdap-versioning, or defining versioning > directly into the extension. We do mention the versioning draft in other places. I don't think it needs to be added here. Also there is other, newer text regarding interoperability vs policy. See the PR. JG-I'll review it once it's included in a new version of the draft for comment. > > “Contracting a set of values when that set is not defined in an IANA registry > to be found in a protocol element in a request” – Wouldn’t this be considered > a non-breaking change unless it was a value provided by the client in the > query? The client would support a superset of values, so the removal of one > of the values should not break a client expecting the old interface. Correct. "in a request" means query. This is not an issue in the response. JG-Thanks for point that out __ > > I like scoping the sub-sections of Section 5.4.3 with “replacements”, which > as when the extension identifier changes. We need to ensure that the > strategies are explicitly not considered. Why? They are both valid under STD95. JG-STD95 speaks nothing of replacements, so other strategies would also be considered valid under STD95. Changing the title of Section 5.4.3 from "Compatibility of Replacements" to "Extension Replacement Considerations" or now "Extension Superseder Considerations" properly scopes the strategies to apply when changing the extension identifier. Even if Section 5.4.3 is properly scoped to superseders, I believe the list of strategies still need to be considerations, since there is no operational experience with either of the strategies listed. In describing Section 5.4.3, it says " Implementers of such changes should consider the following...", so changing the title to considerations is appropriate. > Considering that designers and implementers may take different approaches > that listed in the sub-sections, to clarify this I would add the word > “non-exhaustive” to to the last sentence. > > > > OLD > > > > Strategies for using a replacement in a transition are described below. > > > > NEW > > > > The non-exhaustive list of considerations for using a replacement in a > transition are described below: I don't see how this helps. Are there other known strategies? JG-According to draft-ietf-regext-rdap-extensions, would the use of another strategy would be considered non-compliant? Yes, other strategies are covered in Section 7 "Transition Considerations" of draft-ietf-regext-rdap-versioning. We include the term non-exhaustive there as well, since I view them strictly as considerations thought out ahead of time, but there is no real operational experience in RDAP. My experience with the "Default Version with Client Override" consideration in draft-ietf-regext-rdap-versioning is based on EPP and the negotiation of the greeting and login services or explicit input in the command to override the default version. Are you aware of operational experience with the strategies defined in draft-ietf-regext-rdap-extensions? > Section 5.4.3.1 “Non-overlapping Replacements” > > > > This is certainly an option, but I haven’t seen an instance where this has > been implemented in new versions of an RDAP extension. I don’t have an issue > included this consideration if the sub-sections of 5.4.3 are defined as a > non-exhaustive list of considerations. > 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. > > > 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? -andy, no hats _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
