On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton <[email protected]> wrote:
> Hi Martin, > > > On 09/11/2018 16:31, Martin Bjorklund wrote: > >> Juergen Schoenwaelder <[email protected]> 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. 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/> >>> >>> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> . >> >> > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
