[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-15.txt

["Gould, James" <[e-mail]>]

Andy, 

My responses are included below, prefixed with "JG-".

-- 

JG 



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 




On 8/21/26, 4:40 PM, "Andy Newton" <[e-mail] <mailto:[e-mail]>> 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/21/26 10:18 AM, Gould, James wrote:
> 
> Consider the use case of a bis draft of the redacted extension in RFC 9537 that only wants to remove the use of JSON Path, which we've brought up in the past. In this use case the child members of "prePath", "postPath", "replacementPath", and "pathLang" would be removed. The bis draft could use opaque versioning by bumping the extension identifier from "redacted" to "redacted2". How would the application of the strategies in draft-ietf-regext-rdap-extensions apply to this use case? With the "Standalone Superseders with Versioning" strategy, the bis draft simply removes the needed child members, bumps the extension identifier, and then leverages the versioning extension in the transition from "redacted" to "redacted2" with a transition period. 


Isn't this non-overlapping superseders in Section 5.4.3.1?

JG-No, the successor "redacted2" extension does not "replicate all the functionality of the predecessor" of the predecessor "redacted" extension.    

> By adding support for extension relationships in the versioning draft, the server can signal support for both redacted extensions (predecessor "redacted" and successor "redacted2") with the relationship, the start, the end of each extension, and which extension is the default.


Isn't this section 5.4.4?

JG-No, since the extension identifier is being changed from "redacted" to "redacted2", the successor extension is considered a superseder and therefore one of the two strategies defined for superseders needs to be followed.  Neither strategy (non-overlapping superseders in section 5.4.3.1 nor the overlapping superseders in section 5.4.3.2) apply to what I described.  The strategy of defining a superseder extension that stands alone from the predecessor and leverages an extension like the versioning extension to support the transition needs to be formally defined as a valid strategy, which is what I'm referring to as the ""Standalone Superseders with Versioning" strategy.  

-andy