[regext] Re: some feedback on draft-ietf-regext-rdap-versioning

[Mario Loffredo <[e-mail]>]

Hi all,

just make some comments on Jim's reply .

Please find them below prefixed with [ML].

Il 18/11/2024 19:14, Gould, James ha scritto:
> 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 [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 11/15/24, 4:18 PM, "Andrew Newton 
> (andy)" <[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. 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.
[ML] I agree with Jim, We should preserve the meaning of that sentence 
that captures the goal of the document, i.e providing support for 
structured versioning.
> 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].”
[ML] I agree that the sentence is a bit misleading and needs to be 
clarified.
> 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.
[ML] I don't agree too.   Let's clients select their best option.
> 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.

[ML] I wouldn't change the scope of this document. The document is about 
extension versions which can be negotiated by clients and servers. If 
there is a requirement for adding the server version along with other 
server information,  it should be addressed by a separate  document.


Best,

Mario

> -andy _______________________________________________ regext mailing 
> list -- [e-mail] <mailto:[e-mail]> To unsubscribe send 
> an email to [e-mail] <mailto:[e-mail]> 
> _______________________________________________ regext mailing list -- 
> [e-mail] To unsubscribe send an email to [e-mail]

-- 
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo