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

[Andy Bierman <[e-mail]>]

On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton <[e-mail]> wrote:

> Hi Martin,
>
>
> On 09/11/2018 16:31, Martin Bjorklund wrote:
>
>> Juergen Schoenwaelder <[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.


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/>
>>>
>>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>