[regext] Re: Review of draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions

[James Galvin <[e-mail]>]

Speaking as co-Chair,

I would really appreciate some other voices here.

I understand Jim’s comments to be distinguishing these documents, 
although he does suggest some integration options in his detailed 
comments.

So, taking a step back, the question(s) for the working group is do we 
agree there are three problems to solve or less than three?  If less 
than three, what are they, if any?

To frame the questions a bit differently, let me ask this: I appreciate 
there may be interest in these problems, but does that interest rise to 
level of need a standards track document?  Speaking as co-Chair, 
interest of the few is not consensus.

As a related question, if we agree there is a problem to solve, what is 
the impact on jsContact, if any?

Jim
co-Chair REGEXT



On 22 Jul 2024, at 11:29, Gould, James wrote:

> Jim,
>
> I believe we’ve discussed the problem being solved by the draft’s 
> multiple times.  To be clear, these are the problems that I see the 
> drafts solving:
>
>   1.  draft-ietf-regext-rdap-versioning – While progressing the most 
> recent RDAP extensions it was agreed that there was no formal 
> versioning in RDAP other than what is referred to as opaque 
> versioning.  draft-ietf-regext-rdap-versioning provides for extensible 
> versioning in RDAP, with support for the server to provide versioning 
> information to the client in the help and the query responses and 
> support the capability for the client to provide the hint of the 
> desired extension versions in the query.  There is built-in support 
> for Opaque Versioning and Semantic Versioning and there is support for 
> the client to provide the hint of the desired extension versions using 
> a query parameter or using draft-ietf-regext-rdap-x-media-type.
>   2.  draft-ietf-regext-rdap-x-media-type – Andy and Jasdip can 
> provide a better description, but my take is that 
> draft-ietf-regext-rdap-x-media-type enables a client to provide the 
> hint of the desired extensions using an HTTP header, which survives 
> redirects.
>   3.  draft-ietf-regext-rdap-extensions – Based on the large volume 
> of discussion on the mailing list related to extension identifiers, it 
> was clear that guidance was needed for RDAP extensions, which I 
> believe is the purpose of draft-ietf-regext-rdap-extensions.  I see 
> this draft as meeting the need that RFC 3735 does for EPP, so we can 
> really consider many areas of RDAP extension guidance in this draft.  
> Again, Andy and Jasdip can provide the authoritative description for 
> this draft.
> Thanks,
>
> --
>
> JG
>
> [cid87442*image001.png@01D960C5.C631DA40]
>
> 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/>
>
> From: James Galvin <[e-mail]>
> Date: Monday, July 22, 2024 at 1:21 PM
> To: James Gould <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: [EXTERNAL] Re: [regext] Review of 
> draft-ietf-regext-rdap-versioning, 
> draft-ietf-regext-rdap-x-media-type, and 
> draft-ietf-regext-rdap-extensions
>
>
> 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.
>
>
> Speaking as co-Chair:
>
>
> Thank you Jim for these detailed comments.
>
> For the working group, the question that will be before us in the 
> discussion on Wednesday, which was also before us at IETF119, is what 
> problem are we trying to solve? The second order question, which was 
> also before us at IETF119, is what is the relationship between these 
> documents. Jim’s note is a pretty deep consideration of that second 
> question.
>
> Please come prepared on Wednesday to discuss the first question. There 
> will be Chair slides later today with more details.
>
>
> Thanks,
>
> Jim
> co-Chair REGEXT
>
>
> On 22 Jul 2024, at 7:59, Gould, James wrote:
> Hi,
>
> I did a detailed review of the three drafts 
> draft-ietf-regext-rdap-versioning, 
> draft-ietf-regext-rdap-x-media-type, and 
> draft-ietf-regext-rdap-extensions for alignment.  The following are my 
> findings:
>
>
>   1.  draft-ietf-regext-rdap-versioning includes support for 
> draft-ietf-regext-rdap-x-media-type and the “versioning” query 
> parameter for the client to provide a hint of the extension versions 
> to include in the RDAP query and RDAP response.  The server MUST 
> support both methods and the client MUST include a single method in 
> the RDAP query to ensure that there are no conflicts.  This ensures 
> that clients can specify the extension versions via a query parameter 
> and via an HTTP header per draft-ietf-regext-rdap-x-media-type.
>   2.  draft-ietf-regext-rdap-x-media-type could be merged into 
> draft-ietf-regext-rdap-versioning, since it now represents one method 
> of an Extension Versioning Request.
>
>      *   An alternative is for draft-ietf-regext-rdap-x-media-type to 
> support a more generic form of query parameters for use in any RDAP 
> extension.
>      *   The extension can stay separate if there is some advantage.
>
>   1.  draft-ietf-regext-rdap-versioning defines a Extension Version 
> Identifier in section 3.1 
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-versioning#name-extension-version-identifie<https://secure-web.cisco.com/1_MBwhG1qjXRHnMMq9TlFEdX_SLq1eE5Gvice0sxS8g7VpHB9Oa09-LzBt-J0Qg47q8COFBayFNpnYh3b9MhJyNIJBI0BSGk_eunPgHve0N3e37fOME3HtGysbmAELZ7zKZIojO-ntRsg2PJyzVbEeLuHaIKZ2h20Flr3ynIL9zWgU-7KOTCKrRR7xzzRkP6UZrURE8eSBeJwSGYpIg_GP1VyOIAPx_1kZGeAEQGhpQNn76rMuL_l0IUU4uCcp2efxUo4RpCot86OFi6PPcEd4M1R-PqG6Utxqji6OfIdbTs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-versioning%23name-extension-version-identifie> 
> as:
>
>      *   ABNF
>
>                                                               i.      
> extension-version-identifier = identifier versioning
>
>                                                              ii.      
> identifier = ALPHA *( ALPHA / DIGIT / "_") ; Extension Identifer
>
>                                                            iii.      
> versioning = ["-" 1*VCHAR]
>
>      *   draft-ietf-regext-rdap-x-media-type needs to also support the 
> extension-version-identifier to use it with 
> draft-ietf-regext-rdap-versioning, which currently uses the language:
>
>                                                               i.      
> “This media type has a parameter of "extensions" which is a 
> whitespace-separated list of RDAP extensions as defined in the IANA 
> RDAP Extensions registry.”
>
>            *   How about making this more generic to support 
> additional types of extension versioning schemes, such as the 
> language:
>
>               *   “This media type has a parameter of "extensions" 
> which is a whitespace-separated list of RDAP extensions, such as 
> defined in the IANA RDAP Extensions registry.”
>
>                                                                                                                                       i. 
>      Use of the IANA RDAP Extensions registry will support Opaque 
> Versioning in draft-ietf-regext-rdap-versioning, where use of “such 
> as” will allow for additional RDAP extensions schemes.
>
>                                                              ii.      
> “the values in the media type's extension parameter SHOULD match the 
> values in the rdapConformance array in the return JSON.”
>
>            *   The Extension Version Identifier does include the 
> extension identifier, so the question is whether inclusion of the 
> versioning suffix will meet the “match the values in the 
> rdapConformance array”.
>            *   How about making this more specific to directly 
> reference the version identifiers, which would work better with 
> draft-ietf-regext-rdap-versioning:
>
>               *   “the extension identifier values in the media 
> type's extension parameter SHOULD match the values in the 
> rdapConformance array in the return JSON.”
>
>            *   “though clients SHOULD list the extension identifier 
> in the extensions parameter when using other protocol elements of 
> those extensions.  Servers SHOULD NOT require the usage of extension 
> identifiers in the extensions paramater when other extension protocol 
> elements are used.
>
>               *   To support draft-ietf-regext-rdap-versioning, this 
> could be modified as:
>
>                                                                                                                                       i. 
>      “though clients SHOULD list the extension identifier in the 
> extensions parameter when using other protocol elements of those 
> extensions.  Servers SHOULD NOT require the usage of extensions 
> identifiers in the extensions parameter when other extension protocol 
> elements are used”
>
>                                                                                                                                      ii. 
>      Referencing extension instead of extension identifier would be 
> more generic to support the Extension Version Identifier.
>
>                                                                                                                                    iii. 
>      Nit – replace “paramater” with “parameter”
>
>   1.  draft-ietf-regext-rdap-x-media-type Security Considerations 
> parameter below may be best to address in 
> draft-ietf-regext-rdap-versioning and even more generically in 
> draft-ietf-regext-rdap-extensions
>
>      *   “This specification does contrast with solutions using 
> query parameters in that those solutions require servers to blindly 
> copy query parameters into redirect URLs in situations where such 
> copying could cause harm, such as copying an API key intended for one 
> server into the redirect URL of another server.”
>
>   1.  draft-ietf-regext-rdap-x-media-type B.2 “Query Parameters 
> Considered Harmful” could be moved to 
> draft-ietf-regext-rdap-extensions, since query parameters are used in 
> many places in RDAP, so providing clear guidance when a query 
> parameter should or should not be used would be useful in 
> draft-ietf-regext-rdap-extensions.  I don’t believe query parameters 
> are “harmful” but has a disadvantage in the use cases presented.  
> The query parameter has the advantage of being a simple approach for 
> clients to provide their hint when directly interfacing with the 
> server.  In re-reviewing draft-ietf-regext-rdap-extensions it does 
> look like section 12 “Redirects” includes some guidance related to 
> query parameters, where I believe it would be beneficial to have a 
> separate query parameter section in draft-ietf-regext-rdap-extensions.
>   2.  draft-ietf-regext-rdap-x-media-type B.2.4 “Architectural 
> Violations” and B.3 “RDAP Extension Versioning” could be 
> removed, since I don’t see how the use of a query parameter in RDAP 
> would be considered an architectural violation and RDAP Extension 
> Versioning will be worked on in parallel in 
> draft-ietf-regext-rdap-versioning.
>   3.  draft-ietf-regext-rdap-versioning
>
>      *   In section 8 “Extension Versioning”, I just want to 
> confirm that draft-ietf-regext-rdap-versioning address the normative 
> language and if not what needs to be added:
>
>                                                               i.      
> “If a future RFC defines a versioning scheme (such as using the 
> mechanims defined in section Section 
> 2<https://secure-web.cisco.com/141yE73XKv2NLc7O2rVUTJ_4y2IpMgJTa-QoamzcGlrHgDPVp7u8jHdUqVvbraHil7_y1TUSzgTR77fR4qybyICTJOl28Z1CtMRDi8tMB4pf1praTqIowh-F-9eDu7CiX4GzQcUbLhV7xilhB7LhatlvZAi4k7txt-jKGKtaTfyEDiWP-VItrpXgYpigOFQw9eqPJLbmOVsU5kxb6_WPpKJctmnasbi5FiSxA-B0E5Loh11TAntVf2uthDiZ8U6Xb3L1rZ6P8eYf02gp3aqQtT6PwIPGFZuQmXVrflHHdLuA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions%23extension_identifier> 
> ), an RDAP extension definition MUST explicitly denote this 
> compliance.”
>
>      *   Section 8.1 “Backwards-Compatible Changes”
>
>                                                               i.      
> This section may not be needed with draft-ietf-regext-rdap-versioning, 
> since the set of supported extension versions are explicitly 
> specified, where in the case of Opaque Versioning the server could 
> support many versions of the extension.
>
>      *   Section 8.2 “Backwards-Incompatible Changes”
>
>                                                               i.      
> IT would be helpful to include the reference to 
> draft-ietf-regext-rdap-versioning as an option to consider in 
> signaling support for more than one version of an extension.
>
>      *   Section 9 “Extension Identifiers in a Response”
>
>                                                               i.      
> You can update the reference of [I-D.gould-regext-rdap-versioning] to 
> be [I-D.draft-ietf-regext-rdap-versioning].
> Thanks,
>
> --
>
> JG
>
> [cid87442*image001.png@01D960C5.C631DA40]
>
> 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://secure-web.cisco.com/16eLJyBzKynyyP1bYXROFzMDBfEPhoAFdCM5MViJ0eO3tBXTX0LFFoKOEv63okfIyCAClPsGsGtg8FXeCMNIfjMNT4PN8oSZyhnSAaX2JMKqfvJZOr06_nlmS3rcuKEplIuSv-WXtKFs449uwoh7-LMwT2mH450eJXw6L-eP1ljicpYKpB5WCJX5rSFSlFslBV0aBdOAse1nT5wVDNMB-iZ8npnSmazO0nDg48OIJFaNsJ_tsSqCC7zx5h3tV9H5KHceO_iN5wxWmimbgh095XIUS1CXU1qO5GcMSAAm4SVw/http%3A%2F%2Fverisigninc.com%2F>
>
> _______________________________________________
> regext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]