[regext] Re: RDAP versioning draft feedback

[Mario Loffredo <[e-mail]>]

Hi Pawel,


Il 12/11/2024 08:27, [e-mail] ha scritto:
>
> Hi Jim,
>
> Looking forward to more motivation information from the authors then 
> and Andy.
>
> Adding yet another versioning type seems to me going into direction of 
> even more complexity. My argument was rather to just stay with opaque 
> and restrain from defining anything beyond that.
>
>

Based on the fact that the use of opaque versioning results in managing 
a deprecation process at every server change, I believe that semantic 
versioning goes into direction of less complexity.

AFAIK changes on REST APIs are most likelty additive as the must is to 
avoid breaks as much as possible, likewise I expect the same trend in RDAP.

Hence, IMO semantic versioning would be preferable.


Best,

Mario



> I would like also to feedback on this particular issue of normative 
> MUSTs in "start" and "end" attributes.
>
> > [JG] I’m not clear why removing an expired version from the list of returned with a 
> normative MUST poses an issue.  A client would know based
> > on the normative MUST that any “end” extension version identifiers 
> would not have already expired.  Clients will know in-band when an
> > extension version identifier is going to be supported or going to be 
> removed.  This does come into play when a server is implementing an
> > Internet Draft that goes through many versions.  An example is 
> changing the versioning extension from version “0.2” to “0.3” in 
> draft-ietf->
> > regext-rdap-versioning-02.
>
> From the draft:
>
> "start:" - [...] Once the date and time has passed, the "start" member 
> MUST be removed.
>
> "end" - [...] Once the date and time has passed, the extension version 
> object MUST be removed and the extension object MUST be removed if the 
> last extension version object is removed.
>
> There seems to be a lot of focus put on time as the prime dimension 
> when the versions are phased in or out. I would argue it is the only 
> way of doing it or even if this is the common operational practice 
> these days.
>
> In case of "end" it shall communicate, that after this date the 
> extension version may not be available anymore. It should remain 
> purely informative and tell the client: "if you are using this 
> extension, you likely have a problem beyond this date. Take care to 
> move to a newer version or other functionally equivalent extension". 
> No more than that. Operationally the operator may for example want 
> deploy a new version of RDAP server without support for this 
> particular extension version after this date, not to break this 
> promise, so it should be just OK to have a version supported beyond 
> the date announced as "end".
>
> Similar for "start", if this ought to be an information when operator 
> would start supporting the version and be an indicator that the 
> version is not yet there, but will be... eventually. The operator 
> should be able and allowed to deploy it even before this date or also 
> after. Other aspect is if the operator will even have enough 
> information to provide "start" date if the RDAP server software would 
> be coming from a third party and the software provider wouldn't be 
> able to tell when the operator would deploy the new version, so it 
> would have to be a kind of configuration option that the operator 
> would have to maintain.
>
> So if the new version of the extension is deployed, the "start" date 
> would just disappear. So I would rather state the "start" MUST NOT be 
> announced for an already supported extension version. Or would that 
> also not always be true? For example if the operator would like to 
> have an extension version supported, but as "preview" or "beta"? Would 
> "start" then indicate an official support? Just don't get me wrong - 
> I'm not trying to add even more features, rather to state that "start" 
> is either operationally difficult, misleading or semantically not 
> precise enough to be useful. So let's rather drop it.
>
> Just a proposal: maybe the whole lifecycle could be done much easier 
> just providing a simple status field to the extension version: 
> "deprecated", "productive" (default if not provided), "beta".  For 
> "deprecated" maybe "supportedUntil" could be useful.
>
>
> And one more thing.
>
> The draft is about extension versioning. How about RDAP version 
> itself? If the argument would be that clients need all of those 
> functionality of versioning for interoperability, wouldn't it be to 
> the same way applicable to the protocol itself? It would be useful for 
> the clients if there would be one mechanism same for protocol and 
> extensions, not two.
>
> Kind Regards,
>
> Pawel
>
>
> On 11.11.24 18:52, Gould, James wrote:
>>
>> Pawel,
>>
>> Pawel, thank you for your feedback.  The co-editors of the versioning 
>> and x-media drafts met at IETF-121 and agreed to the following:
>>
>>  1. Add reason language to the semantic versioning section.  Andy
>>     Newton is going to provide the use case information that is
>>     associated with his experience with investigating RDAP issues.
>>  2. Look to add more meta-data in the /help response.  Andy Newton to
>>     provide sample JSON for the additional meta-data.
>>  3. Update x-media to reference the Extension Version Identifier ABNF
>>     in versioning, which will ensure compatibility.
>>  4. Add support for temporal versioning, based on RFC 3339
>>     <https://datatracker.ietf.org/doc/html/rfc3339>.
>>      1. It would be good to get your feedback with adding a third
>>         versioning type, since you asked the question about the need
>>         to define and register the versioning types.
>>      2. To answer your question, we know that there are two types of
>>         versioning (opaque and semantic) discussed thus far, but
>>         there may be other types considered in the future.  Adding
>>         the temporal version type would provide another example.
>>  5. “rdapx” to be added in the RDAP Extensions Registry for x-media.
>>  6. x-media to look to use “rdap-x+json” in the accept header and to
>>     use the existing “rdap+json” in the content-type header.  Andy
>>     Newton will check with SMEs on this.
>>  7. Agreed to keep the x-media and versioning drafts separate with
>>     normative reference between them.
>>
>> I provide additional responses to your feedback embedded below, 
>> prefixed with “[JG]”.
>>
>> -- 
>>
>> 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: *"[e-mail]" <[e-mail]>
>> *Date: *Monday, November 11, 2024 at 12:02 PM
>> *To: *James Gould <[e-mail]>, "[e-mail]" 
>> <[e-mail]>, "[e-mail]" <[e-mail]>
>> *Subject: *[EXTERNAL] Re: [regext] Re: RDAP versioning draft feedback
>>
>> Hi Jim,
>>
>> To recap on what we discussed in Dublin and to also have input from 
>> the working group.
>>
>> Jasdip stated a very valid question. Reading through the draft in 
>> more detail I also have a feeling that we are trying to use a 
>> sledgehammer to crack a nut.
>>
>> The problem to solve was that RDAP was lacking of clear way of 
>> signalling that there is a different version of the same extension, 
>> so the client would know that foo1 and foo99 are indeed version of 
>> the same extension and not different unrelated extensions.
>>
>> What the draft proposes is very feature reach, but does not tell a 
>> lot about why clients and servers should spend time implementing all 
>> of its features. Do we expect an RDAP extensions to have tens or 
>> hundreds of versions, so that the clients would need to apply a logic 
>> of semantic versioning to work on ranges of versions and 
>> distinguishing major and minor versions? If we talk about extensions 
>> from IETF control this is not likely to happen, just because of how 
>> IETF process works. Why do we need extensibility to even support more 
>> versioning semantics (Versioning Type)?
>>
>> [JG] We will be adding the reason language for the semantic 
>> versioning, but providing the meta-data in the /help response would 
>> help for software clients and client users trying to troubleshoot 
>> issues.  The versioning type definition and registration makes sense 
>> for what we know today.  Other forms of versioning could be created 
>> in the future with the temporal type in, based on RFC 3339 
>> <https://datatracker.ietf.org/doc/html/rfc3339>, may being added to 
>> the draft as well.  Please let us know whether you support adding the 
>> temporal type.  I know from implementing EPP extensions that are not 
>> RFCs, having versioning provides isolation and the ability for the 
>> co-editors to encourage implementation without risking breaking clients.
>>
>> What we expect clients to do with all the related lifecycle 
>> information (start/end/default)? I can make some usefulness for the 
>> "end" attribute (like warning about using deprecated interface), but 
>> mandating the server (normative MUST) to remove the support exactly 
>> at this time seems like a void requirement, as operationally quite 
>> hard to fulfil unless the server would implement special logic for 
>> management of versions of extensions. A bit of overhead for very 
>> little gain if you ask me. "start" is something with even less 
>> usefulness as we are talking about future version. Here there are a 
>> lot of assumptions that the server deploys a future version and only 
>> activates it later at a given point in time. Again a logic not really 
>> needed. The client will learn about new version when it's there and 
>> supported by client anywhere.
>>
>> [JG] I’m not clear why removing an expired version from the list of 
>> returned with a normative MUST poses an issue.  A client would know 
>> based on the normative MUST that any “end” extension version 
>> identifiers would not have already expired. Clients will know in-band 
>> when an extension version identifier is going to be supported or 
>> going to be removed.  This does come into play when a server is 
>> implementing an Internet Draft that goes through many versions.  An 
>> example is changing the versioning extension from version “0.2” to 
>> “0.3” in draft-ietf-regext-rdap-versioning-02.
>>
>> I would double what Jasdip stated below, that opaque versioning - 
>> with just adding semantics to one symbol "-" splitting extension 
>> identifier into name and version would do the same good job and be a 
>> way simpler.
>>
>> [JG] Adding the use of the ‘-‘ delimiter with a version is exactly 
>> what draft-ietf-regext-rdap-versioning is doing, but maintaining 
>> compliance with the base RDAP RFCs by not touching the extension 
>> identifiers in the rdapConformance.
>>
>> If someone would like to release a new version of their extension 
>> every month (as sais likely outside of IETF), another semantic for 
>> versioning would be good for it and within the opaque version part. 
>> But then it might be a part of their particular specification and 
>> would only concern clients dealing with this particular extension.
>>
>> K.I.S.S.
>>
>> [JG] The external version identifier pretty much matches the concept 
>> of the XML URI in EPP and the extension identifier prefix matches the 
>> concept of the XML prefix, which means that an updated draft can add 
>> features reflected in the version extension identifier without having 
>> to touch the extension identifier prefix.  The whole idea is not to 
>> require to communicate versions out-of-band (e.g., EPP 03/07 or 05/07 
>> for those that have been around for a while) when the extension 
>> identifier does not change between extension versions with material 
>> changes.
>>
>> Kind Regards,
>>
>> Pawel
>>
>> On 03.11.24 22:50, Gould, James wrote:
>>
>>     Rationale for versioning:
>>
>>     Section 1 says, “The RDAP Conformance values are identifiers with
>>     no standard mechanism to support structured, machine-parseable
>>     version signaling by the server.” It’d be good to elaborate with
>>     usage scenarios where such structured versioning is a value-add
>>     for clients beyond what the opaque (no inner meaning) extension
>>     identifiers from STD 95 afford. Let’s say an extension is “foo1”,
>>     then “foo99”, and later “foo2” in terms of “versions”. The server
>>     announces its support for these non-structured extensions, say,
>>     on its web site or through the “rdapConformance” member in a
>>     /help response, and the clients can then negotiate a particular
>>     non-structured version of this extension using the standard HTTP
>>     content negotiation methodology (e.g., using the RDAP-X media
>>     type). In the spirit of what-not-to-do, it is fair for a client
>>     to ask: Why should I go through the overhead of processing the
>>     “versioning_help” member? What value-add does it get me? Is it in
>>     some way a better discovery and/or negotiation method for RDAP
>>     extensions? Would be good to beef up the rationale for structured
>>     versioning.
>>
>>     JG – We need to ensure that RDAP-X supports the extension version
>>     identifier as well, so there should be no variance between the
>>     versioning extension and the RDAP-X extension.  We can add more
>>     rationale in Section 2 “Semantic Versioning”, where a server
>>     could support multiple versions of an extensions that are
>>     signaled as related.  For the versioning extension itself, there
>>     have been multiple versions of it that are not structurally
>>     different and not backward compatible, with the latest version
>>     being “versioning-0.3”.  Other RDAP extensions could leverage
>>     semantic versioning during development to encourage
>>     implementation with version isolation and with clear relationship
>>     between the extension version identifiers.  Do you believe that
>>     we should look to add the concept of relationships between opaque
>>     version identifiers?
>>
>> Kind Regards,
>>
>> Pawel
>>
>
> _______________________________________________
> regext mailing list [e-mail]
> To unsubscribe send an email [e-mail]

-- 
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo