Andy, Thanks for reviewing draft-ietf-regext-rdap-versioning. I provide responses to your feedback embedded below, prefixed with "[JG]".
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/15/24, 4:18 PM, "Andrew Newton (andy)" <a...@hxr.us <mailto:a...@hxr.us>> 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, I just read through the versioning draft and have some feedback. 1. The first clause of the abstract is confusing to me. Maybe something like this: OLD: This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. NEW: This document describes an RDAP extension to describe versioning meta-data of RDAP extensions to be included in RDAP response, and describes methods for client signaling of supported extensions. This extension also specifies two versioning types and a means to add future versioning types, Of course, which is clearer is a matter of opinion so take it or leave it. [JG] I agree with your simplified version. 2. In section 1, the sentence on RDAP conformance values is misleading. I propose: OLD: The RDAP Conformance values are identifiers with no standard mechanism to support structured, machine-parseable version signaling by the server. NEW: The RDAP Conformance values are identifiers that are by default opaque in nature. [JG] I believe it's important to leave this sentence as is. The language is based on the chairs proposal on slide 6 of https://datatracker.ietf.org/meeting/114/materials/slides-114-regext-rdap-extension-identifier-and-rdapconformance, where "explicit support for version is not an integral part of the extension mechanism" and "Certainly, you can choose to include version inside the specification for your extensions, but in the context of the base protocol an extension is either supported or its not, and when supported it simply means there is a shared understanding of what is to be done between the client and server". We need to clear the issue the versioning extension is addressing, which is to provide support for a structured, machine-parseable version signal. 3. The first bulleted point of section 1 describes a client including information in an RDAP response. It should be that the client signals to the server and the server includes the information in the response. [JG] The language is “Enabling a client to specify the desired RDAP extension versions…”. The RDAP extensions can apply to the query and the response, so the hint can apply to either. How about changing it to read “Enabling a client to specify to the server the desired RDAP extension versions included by the client in the RDAP query and for the server to include in the RDAP response, using the Extension Versioning Request (Section 3.2).” The second sentence can be simplified to not have to repeat this with “The client can specify the desired RDAP extension versions with the “versioning” query parameter or the RDAP-X media type “extensions parameter [I-D.ietf-regext-rdap-x-media-type].” 4. Section 3.2 paragraph 1 gives equivalency to both signaling methods, but the query parameter may not always work. I suggest the following: OLD: The client MAY provide an Extension Versioning Request to indicate the desired extension versions to include in the RDAP query and RDAP response. There are two Extension Versioning Request methods with the Versioning Query Parameter (Section 3.2.1) and the Versioning Extensions Media Type Parameter (Section 3.2.2). The server MUST support both methods of Extension Versioning Request methods and the client MUST use at most a single Extension Versioning Request method in the RDAP query. NEW: The client MAY provide an Extension Versioning Request to indicate the desired extension versions for inclusion in an RDAP response by a server. There are two Extension Versioning Request methods: Versioning Extensions Media Type Parameter (Section 3.2.2) and Versioning Query Parameter (Section 3.2.1). The Versioning Extensions Media Type Parameter should be the preferred signaling method as there are known limitations regarding propagation of query parameters (see draft-ietf-regext-rdap-extensions). The Version Query Parameter is used provided to aid in troubleshooting of RDAP services. The server MUST support both methods of Extension Versioning Request methods and the client MUST use at most a single Extension Versioning Request method in the RDAP query. [JG] I don’t agree with including a preference between the two methods. The extension supports both with a requirement for the server to implement both and the client to choose what best meets their requirements. I don’t believe the versioning extension should replicate the reason for the X-Media extension considering that the X-Media extension is a normative reference. 5. Swap section 3.2.2 and 3.2.1. [JG] I don’t see a reason to swap the sections, considering that there is no preference between the two. 6. The "version" JSON member should be marked required in the "versions" array described in 3.3.2. [JG] Agreed 7. When troubleshooting RDAP servers, there is other helpful information that would be greatly beneficial regarding the server version. I propose defining two objects for "versioning_help", one about the server and one about the extensions. Here is prototype: "versioning_help": { "server" : { "server_id": "1", "version": "1.2", "type": "semantic", ... } "extensions": [ { "extension": "rdap_level_0", "type": "opaque", ... }, { "extension": "versioning", "type": "semantic", ... } ] } "extensions" would be the array currently defined in "versioning_help". "server" would have all the same JSON members as a "version" object with the addition of "server_id" which is a string identifying a specific server in a cluster. [JG} This is an interesting concept that needs more thought. The scope of the draft is associated with extension versioning, so this would be a change in scope (e.g., versioning type, server identifier, server meta-data to include, and overlap with extension versioning). We would need to cover the use cases and determine the applicability of the features included in the versioning extension to apply to server versioning. I don’t recommend inclusion of server versioning yet without more discussion on the mailing list, since this may be better suited for another RDAP extension targeted to the use case. -andy _______________________________________________ regext mailing list -- regext@ietf.org <mailto:regext@ietf.org> To unsubscribe send an email to regext-le...@ietf.org <mailto:regext-le...@ietf.org> _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
