Re: [regext] RDAP Extensions Approach Analysis v2

[Jasdip Singh <[e-mail]>]

Hello Andy,

On 7/1/22, 8:29 AM, "Andrew Newton" <[e-mail]> 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 <[e-mail]> 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