Hi Pawel,
plase find my comments inline prefixed with [ML].
Il 14/11/2024 16:00, kowa...@denic.de ha scritto:
Hi Mario,
I would really like to see how many versions we envision to be facing
in the lifecycle of an extension.
[ML] Honestly don't know how many versions an extension could have, they
could be many or just one.
If we also consider the versions before publishing the spec (which are
versions themselves) , the number of versions is not so little.
In addition, we should consider that RDAP is still in its growth phase
and most of the extensions published so far have little or no
implementations.
I expect that some of them will be revised as the number of live
implementations will be increasing.
Anyway this not the point in my opinion. The point is to make both
clients and servers to face the lowest impact in their own
implementation when managing the transition between two versions.
We are talking here not of version of an application software, but of
a specification. So not every server change would lead to deprecation
process. The specifications do not rotate that often to justify
semantic versioning. Especially the draft defines own semantic
versioning instead of taking just the one from https://semver.org/
which means custom development to be compliant.
[ML] As I wrote above, what concerns me the most about opaque versioning
is that any change to the extension has always the maximum impact to
both client and server implementations.
If there is no-braking change then the version is just informational
for the client.
[ML] I'm not convinced about that. When opaque versioning is used, every
change results in managing a transition process regardless of whether
the change breaks the API or not and the impact on both client and
server implementations is always the maximum, i.e. any update to a spec
extending RDAP with both query and response features affects all of them
regardless of the actual scope of the update.
Let's take for example the reverse search extension. if opaque
versioning was the only one into force and I had to simply add an
optional member to the reverse_search_properties JSON member of the help
reponse, I should manage the duplication of both
reverse_search_properties and reverse_search_properties_mapping response
members as well as the duplication of all the paths including the
segment "/reverse_search/".
Not so efficient, if we think that, in this case, servers could signal
clients about the existence of a new version in their implementation and
easily manage the transition between the two versions by leveraging the
JSON feature that allows clients to ignore the optional unknown JSON
members. On the other side, clients could simply add the handling of the
optional JSON member in their implementation at their convenience.
If there is a breaking change then the client must be aware of the
version it supports and this can be covered likely with the same
effect by taking new extension identifier. Also here range
compatibility, that semantic versioning brings, is likely more than
needed for the use case.
[ML] I personally see that opaque versioning is more suitable to manage
breaking changes as it inherently allows to isolate the extension
features in the implementation while semantic versioning is preferable
to manage non-breaking changes as it allows to preserve those extension
features which are not directly affected by the change.
I recap here in the following a list of possible breaking and
non-breaking changes. Based on it, I'm inclined to think that the former
would be much less likely than the latter.
*Breaking changes include:*
* *removing an entire operation*
* *removing or renaming a parameter*
* *removing or renaming a response field*
* *adding a new required parameter*
* *making a previously optional parameter required*
* *changing the type of a parameter or response field*
* *removing enum values*
* *adding a new validation rule to an existing parameter*
* *changing authentication or authorization requirements*
*Additive **(non-breaking) **changes include:*
* *adding an operation*
* *adding an optional parameter*
* *adding an optional request header*
* *adding a response field*
* *adding a response header*
* *adding enum values*
Another possible solution to partially limit the impact of a version
change when opaque versioning is used could be to define as many opaque
extension identifiers as the features defined by the extension so that a
change in one feature wouldn't affect the others. This has been used
with different purposes in the rir-search draft.
Best,
Mario
Kind Regards,
Pawel
On 12.11.24 12:18, Mario Loffredo wrote:
Hi Pawel,
Il 12/11/2024 08:27, kowa...@denic.de 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
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: *Monday, November 11, 2024 at 12:02 PM
*To: *James Gould <jgo...@verisign.com>, "jasd...@arin.net"
<jasd...@arin.net>, "regext@ietf.org" <regext@ietf.org>
*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 --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org
--
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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
--
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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
