On 11/11/2018 07:07, Andy Bierman wrote:
On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
Hi Martin,
On 09/11/2018 16:31, Martin Bjorklund wrote:
Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de
<mailto: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.
I agree with Martin that this requirement is a bad idea.
It will make YANG too complicated and error-prone.
This is not the same as versioning the entire API (e.g., /restconf2,
/restconf3).
This is conceptually a version number at every node in the tree.
The "outer" models are ignored by the server in this approach.
Only the "inner" model is actually implemented and validated.
A different set of outer models for each client, based on the set of
modules
the client wants to see, sounds very complicated to design, implement,
test, and operate.
That is not what I'm proposing.
The server exposes one or more different schema of it's choosing. When
the client opens the connection with the server it chooses which schema
to use.
For example, if the server release history was:
Release 1 , supports schema A
Release 1.1, supports schema B
Release 2, supports schema C
Then in release 2, the server may also support the schema associated
with release 1 and 1.1 (i.e. it supports schema A, B and C)
If this seems too complex, then the server chooses to just implement
schema C, associated with release 2, and clients are forced to upgrade
and use the latest schema.
It is not our intention to force servers to implement this version
selection, only to specify it for vendors who did wish to implement it.
Thanks,
Rob
Thanks,
Rob
Andy
/martin
I have not seen a proposal that addresses all requirements
and hence
at the end the WG needs to decide which t
<https://maps.google.com/?q=the+end+the+WG+needs+to+decide+which+t&entry=gmail&source=g>radeoffs
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/
<https://www.jacobs-university.de/>>
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
.
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
