Hi Martin,
On 09/11/2018 16:31, Martin Bjorklund wrote:
Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to provide support
for an old and a new definition, and agreement on the solution.
Do you disagree with the requirement? Or do you disagree with the
consequences of implementing multiple versions of the same module
for some of the proposed new versioning schemes? Or both?
I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2. If this is not the intention of 3.2, maybe it can be
clarified.
Here is what 3.2 says:
3.2 The solution MUST provide a mechanism to allow servers to
simultaneously support clients using different revisions of
modules. A client's choice of particular revision of one or
more modules may restrict the particular revision of other
modules that may be used in the same request or session.
This does _not_ say servers MUST implement this.
Item 3.2 establishes a requirement and for some solutions it may be
easy to satisfy this requirement, for others it may be more costly to
satisfy this requirement.
The whole requirements exercise becomes a rather pointless exercise if
we remove requirements so that certain solutions look more
attractive.
Ok, but that's not what I wrote. I don't agree with this requirement
which says that it MUST be possible for a server to support
different revisions of a given module (again, if this is not the
intention of the text, please clarify). I simply don't think that
this is a good requirement.
One way to think of this is as YANG data models defining an API between
client and server.
There seem to be lots of REST APIs that implement versioning of their
API by having a version number in the URL. In fact, I think that
RESTCONF adopts this approach to allow versioning of the protocol.
One solution is as Andy describes. The underlying server only
implements one version of the a given YANG module, but they may provide
other views on to this data using different versions of YANG modules.
E.g. the same as how Vendor YANG models, IETF YANG models, and
OpenConfig YANG models might be treated as their own views, mapped to
the same internal YANG modules.
Thanks,
Rob
/martin
I have not seen a proposal that addresses all requirements and hence
at the end the WG needs to decide which tradeoffs make sense.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
