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

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

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.  

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 -- [e-mail] <mailto:[e-mail]>
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>