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 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. > 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. > 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). > 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. > > > > 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. > 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. > 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. > * 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. > > “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. > > 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. > 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? > 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. > > > 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. 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. -andy, no hats _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
