Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton <[e-mail]>]

On 11/11/2018 07:07, Andy Bierman wrote:
>
>
> On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Martin,
>
>
>     On 09/11/2018 16:31, Martin Bjorklund wrote:
>
>         Juergen Schoenwaelder <[e-mail]
>         <mailto:[e-mail]>> 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: [phone]         Campus Ring 1 | 28759
>             Bremen | Germany
>             Fax:   [phone]       
>              <https://www.jacobs-university.de/
>             <https://www.jacobs-university.de/>>
>
>         _______________________________________________
>         netmod mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/netmod
>         <https://www.ietf.org/mailman/listinfo/netmod>
>         .
>
>
>     _______________________________________________
>     netmod mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>