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

[Martin Bjorklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> wrote:
> On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > 
> > This is what we have today only if modules are updated in legal ways.
> > The 3.1 requirement says this backward compatibility is maintained even
> > if the module is updated in violation of the module update rules.
> >
> 
> It is stating a requirement. How solutions meet the requirement is for
> the solutions to figure out.
> 
> > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > key leaf to the /modules-state/module list?
> 
> Depends on the solution I guess.
>  
> > IMO the current "deprecate and start over" is actually the easiest
> > and most robust solution path, and it requires no changes to YANG or
> > the protocols.
> 
> Yep. But there are people who think that other solutions can do
> better. The challenge is to find out whether they actually do better
> or for whom they do better (and if someone has to pay a price for it).
> For having this discussions, it is good to write down requirements.
> 
> > >        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.
> > >
> > > Today, the version number is effectively an (implicit) part of the
> > > module name (plus the revision date for backwards compatible changes).
> > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > well.
> > 
> > This is not what we have at all. RFC 7950 says a server can only implement
> > one revision of a module.
> >
> 
> A new version today essentially means a new module name and I do not
> see a conflict with what I wrote.

Then I think this requirement needs clarification.  It says "different
revision of modules", which can be interpreted as different revisions
of *the same* module.

Also the second part of the paragraph seems to indicate multiple
revisions of the same module in the server.

I do not agree with this requirement.



/martin


> 
> > > If we want to increase 'agility' in an attempt to make it easier to
> > > deliver early designs and to fix them on the go, the costs will go up
> > > somewhere. The extreme cases are:
> > >
> > > 1) The server can make changes to YANG modules in arbitrary ways and
> > >    the clients have to adapt, i.e., clients have to pay the bill.
> > >
> > > 2) The server has to provide strict backwards compatibility in order
> > >    to not break clients, i.e., servers have to pay the bill.
> > >
> > >
> > This is not correct. Implementing multiple incompatible revisions of a
> > module
> > (e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
> > server developer.
> 
> Depends on the details and the developer will decide based on the
> impact on the clients and whether a transition period is possible. You
> seem to read that the requirement says one has to implement backwards
> compatibility. This is not what the text says. The text says it must
> be possible.
> 
> > > Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
> > > important requirements.
> > 
> > I do not agree with the premise that non-compatible data model updates are
> > required.
> > 3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
> > a new(much more complicated) version of YANG
> 
> I think you misread the requirements text.
> 
> /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
>