--
JG
cid87442*image001.png@01D960C5.C631DA40
*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/>
*From: *"kowa...@denic.de" <kowa...@denic.de>
*Date: *Thursday, November 21, 2024 at 2:06 PM
*To: *James Gould <jgo...@verisign.com>, "regext@ietf.org"
<regext@ietf.org>
*Subject: *[EXTERNAL] Re: [regext] RDAP versioning - on client-server
interactions and 2-RTT flow
Hi Jim,
Again, the proposal for 1-RTT model is that the client would put a
range of versions it supports into a request and the server would put
best efforts to fulfil it. Like
?versioning=versioning-0.3-versioning-0.9,versioning-1.0+. Current
draft allows listing all supported versions one by one, but this list
may grow big in this case. The draft is not clear about what to do if
server does not support the requested version. Say server supports 0.3
(default) and 0.9 and client requests 0.6. It would be better for the
client that the server responds with 0.9 (best fitting compatible
version with 0.6) rather than with default 0.3.
Also a redirect target server can deliver the best fitting response
rather than falling back to default.
Kind Regards,
Pawel
On 21.11.24 19:26, Gould, James wrote:
Pawel,
The server has a default set of extensions with or without the
versioning extension and will return the defaults. I don’t see
your concern with exposing the supported extension versions in the
help response, since it really doesn’t require a 2-RTT flow. The
lazily option includes the sub-option of manually using the
meta-data to address an error. If there was no versioning
extension, there would be no meta-data within RDAP to use to
determine the root cause of the extension issue when the server
supports more than one version of an extension at a time.
The versioning extension is optional for the RDAP client to
implement, as should be the case for other RDAP extensions,
provides help information in the help response per RFC 9082, and
the help information can be used at any time automatically or
manually when needed. Introducing an optional RDAP extension that
provides extra meta-data in the help response in no way implies
the need for a 2-RTT flow.
Thanks,
--
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://secure-web.cisco.com/1Wv2EPn7C7-lq0WVPWcTsrUPEGLQP0VH_PZJ6W3FGEMShJ6WQrFGrV00PI1XZH6wmHJxSHxXEviOqbCXI7AKeQw0R9_BY6fjiPgX6X3B-ugjuTyXJ8a_xSOzZCVVjf4g154WAMHR288btNwdVKRalmjuYjLY_EE5IHPFIadaRsKUyPjNAdhjJiVDWPeyGtqcPwXPBuqSP-3FjmzjaAKydvLNPrRuhllWtvIQB9S1-eblJKIHkIDy5fcgre6NiJNVuIbBba_rUchnLxVuGaGHkNiWpU01GHMDj7gClM71wgpk/http%3A%2F%2Fverisigninc.com%2F>
*From: *"kowa...@denic.de" <mailto:kowa...@denic.de>
<kowa...@denic.de> <mailto:kowa...@denic.de>
*Date: *Thursday, November 21, 2024 at 1:16 PM
*To: *James Gould <jgo...@verisign.com>
<mailto:jgo...@verisign.com>, "regext@ietf.org"
<mailto:regext@ietf.org> <regext@ietf.org> <mailto:regext@ietf.org>
*Subject: *[EXTERNAL] Re: [regext] RDAP versioning - on
client-server interactions and 2-RTT flow
Hi Jim,
Got it. These are all optimisations of 2-RTT model.
I am missing your feedback to my 1-RTT proposal and risks related
to redirects in 2-RTT scenario.
Kind Regards,
Pawel
On 21.11.24 19:00, Gould, James wrote:
Pawel,
The client has multiple options:
1. Proactively leverage the versioning help with every query
(2-RTT) or a pre-defined intervals to keep the
configuration accurate.
1. I don’t see the extension versions changing frequently
and the versioning extension does support
pre-publishing support for an extension version to the
client, so my recommendation would be to check it
daily or even less frequently in a single client.
2. Lazily leverage the versioning help when there is an
identified extension version issue
1. This could be automated with the first error and then
stored with the correct extension versioning
information for subsequent queries.
2. This could be manual when an error is reported, and
operations uses the versioning help to diagnose the
issue for a fix.
There are probably many additional options, where having the
meta-data along in the versioning help (e.g.,
“versioning_help” member) with the extension versioning detail
with each response (e.g., “versioning” member) should provide
value with any RDAP client to address extension compatibility
issues automatically or manually.
Thanks,
--
JG
cid87442*image001.png@01D960C5.C631DA40
*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://secure-web.cisco.com/11KWO61ONP3_D4UFnzav5ddD672ljzIQFbvruzfwmY-UufG83Q9qeOASRq90wZO8rDn82Gl4ezO8LFsywN9iX3eaC5gYTNS0Ozvj6CU2GBLBBSRCuB6e9EGJKiN-NcQtPiB-HOey2X25gQ3_nyB0nxGbKVW4I55_OmmuVgZhhNnOt8694hHAgDJ3cpDNm5pqCcCUsdenKtJtfBm-zU1I_FIaakyB7wjBqGUrVlscG4wTNhTveqTvx8r4FVlGeYNJygo_yFL8fQACGVkqOV9ksrUYTvvW5KIx1v_eOO6w4acI/http%3A%2F%2Fverisigninc.com%2F>
*From: *"kowa...@denic.de" <mailto:kowa...@denic.de>
<kowa...@denic.de> <mailto:kowa...@denic.de>
*Date: *Thursday, November 21, 2024 at 12:36 PM
*To: *James Gould <jgo...@verisign.com>
<mailto:jgo...@verisign.com>, "regext@ietf.org"
<mailto:regext@ietf.org> <regext@ietf.org>
<mailto:regext@ietf.org>
*Subject: *[EXTERNAL] Re: [regext] RDAP versioning - on
client-server interactions and 2-RTT flow
Hi Jim,
If the client would like to benefit from machine readable
version information from versioning extension, there is no way
around 2-RTT.
If not, then this extension is basically of no practical
meaning to such client, so not really worth considering.
Kind Regards,
Pawel
On 21.11.24 18:29, Gould, James wrote:
Pawel,
RFC 9082 states the following for the Help Path Segment:
The help path segment can be used to request helpful information (command
syntax, terms of service, privacy policy, rate-limiting policy, supported authentication
methods, supported extensions, technical support contact, etc.) from an RDAP server. The
response to "help" should provide basic information that a client needs to
successfully use the service.
This is exactly what the versioning extension is doing in the
"versioning_help" member, by providing help information on supported extensions. A
client is not required to use the versioning extension to perform queries, since the server does
have a default extension version that is specified in the "versioning_help" member. If a
client does run into an extension compatibility issue, it could use the help command to
programmically (lazily) or manually determine the root cause of the issue for resolution.
There is no requirement or expectation that an RDAP client
implement 2-RTT.
Thanks,
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
<mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/> <http://secure-web.cisco.com/1i4F4XceuHxhs-b9i0KfN2SASQv-TqK69F2z5EdAqIhCxvhNvC3WwTfK6ANtRgjWLd-R8d-Cqyv-UD-CDH530aIlcZGBWm2yG1KKtbY1TC3EuirdyZQMdD6m8QZxEis3VeDni07o4rQRu8oP6EsH75zHCBqovfVVxdTQR2RG4TWq-JSOiQGFBxZo-rT98XqthLeXHhlNAGdU4WeXMwzWqT6EUQND3wycz-A1IZhl6TZs0OrUj1i16L6RWb2XC51tpxYvBo1-crVyGevQ5AGLM6MWtAFYuGnkJXhUPgBL98fI/http%3A%2F%2Fverisigninc.com%2F>
On 11/21/24, 12:19 PM, "Pawel Kowalik" <kowa...@denic.de
<mailto:kowa...@denic.de> <mailto:kowa...@denic.de>> wrote:
Hi,
Thinking of interactions between the client and server that
versioning
draft assumes I think we are heading towards 2-RTT model for every
request.
Step 1: The client makes an HTTP GET request to the /help endpoint
of
the RDAP server.
Step 2: The response is processed to extract rdapConformance and
versioning.
Step 3: Compare the server's supported extensions and versions with
those supported by the client.
Step 4: If compatible configurations are found, the client makes
target
request to a resource endpoint (e.g., domain/foo.com), using
headers or
query parameters to specify the desired configuration.
So we have 2 full RTTs. Of course a client can cache it for some
time
but not forever, as the server may change at any time its
configuration.
In a cold state or a client without capability to cache this will be
always 2-RTT if the client would like to be aware of the versions.
I don't think this is in line with rfc7480, which assumes "a client
implementation should be possible using common operating system
scripting tools (e.g., bash and wget)". Also not with the usage
pattern
defined in Section 1. None of it is normative, however I would not
just
ignore it without discussing consequences of going this way.
I would like to see more that versioning draft would assume 1-RTT
model
as a primary use-case, so that the client would put a range of
versions
it supports into a request and the server would put best efforts to
fulfil it. This would be also more "redirect friendly", so that a
redirected request to another server (no matter if with query
parameters
or headers) would have the same information about client
capabilities
and able to serve the response as opposed to getting a request for
configuration crafted for the origin server of a redirect.
Kind Regards,
Pawel
_______________________________________________
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org
