Hello Andy,
On 7/1/22, 8:29 AM, "Andrew Newton" <[email protected]> wrote:
This is very impressive work, Jasdip. I've been trying to follow this
conversation, and this doc is very helpful.
Thanks. :) Glad it is helpful.
I note that in the analysis there are references to "put the new
extension value in the help" (or something). What does this mean?
IIUC what you are referring to is in aspect #5 (Server-side signaling of the
next iteration of an extension) of the analysis [1]: "Add the new value of the
rdapConformance in the help response and related responses". What I simply
meant here is how an extension identifier registered with IANA shows up in RDAP
responses -- in the rdapConformance string array in the "help" and other (e.g.
"domain/<domain name>") responses -- as a server-capability signal.
First, /help is a query unto itself. Second, putting additional
information in a "notice" without proper guidance of what to actually
do may be kicking the ambiguity-can down the road. Is it part of the
title for the notice? Is there a textual description, and if so how
does that work with I18N issues? Does it go into a relative link
structure?
The aspect analysis section is interesting as it helps us to evaluate
the trade-offs. In my opinion, interoperability is paramount otherwise
we'll just be repeating this conversation again in a year. I view
on-the-wire efficiency as the least-compelling objective for this
protocol. And cost to clients should be given higher consideration
than cost to servers given there are many more clients than servers.
I believe this puts me in camp A even if it means we sacrifice some of
the on-the-wire aesthetic.
This is where the analysis landed for me as well.
Jasdip
[1]
https://docs.google.com/document/d/1e3QD8z01KpYRd5LwdLBWjHHDoFVAVEL8u7Y52zsDdx0/edit?usp=sharing
On Mon, Jun 6, 2022 at 10:05 PM Jasdip Singh <[email protected]> wrote:
>
> Hi.
>
> Please find below the revised analysis of the current approach (A) and
the 2 newly proposed approaches (B and C) for RDAP extensions [1]. Hopefully,
the considered change scenarios are now granular enough ( @Mario :) ).
>
> My high-level observations:
>
> Approach C is much better than Approach B.
> That said, would still go with Approach A since it consistently prevents
naming collisions for all change scenarios and affords sufficient transition
time for clients to “upgrade” to the next iteration of an extension. The latter
-- graceful upgrade -- could be quite important to most, if not all, customers
of the RDAP service at an RIR or a DNR, to the point of being an operational
requirement. The former – consistently preventing naming collisions – helps
keep the model simple, albeit at the expense of occasionally sending more data
in responses.
> Approach C is closer to Approach A than to Approach B but requires a
careful scenario-by-scenario analysis to determine the need for a new
prefix(es), and that could be problematic at times. I think it’d come down to
(sunk) cost versus benefit when choosing between sticking with Approach A or
moving to Approach C.
>
> Please feel free to rectify this analysis. :) Hopefully, the discussion
could converge for the considered change scenarios.
>
> Thanks,
> Jasdip
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
