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

["Reshad Rahman (rrahman)" <[e-mail]>]

From: netmod <[e-mail]> on behalf of 'Andy Bierman' <[e-mail]>
Date: Friday, November 9, 2018 at 6:38 PM
To: Juergen Schoenwaelder <[e-mail]>, Martin Bjorklund <[e-mail]>, 'Andy Bierman' <[e-mail]>, NetMod WG <[e-mail]>
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt



On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> wrote:
On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder <[e-mail]<mailto:[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.

Today, you need to create a new module if you make NBC changes to
existing changes (e.g., you change Bool to Int {0..1} and you are not
creating a new leaf). Since there are now two modules, you _can_
implement both modules if that makes sense.


This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.
<RR> I disagree, per https://tools.ietf.org/html/rfc7950#section-4.2.1
   A server may implement a number of modules, allowing multiple views
   of the same data or multiple views of disjoint subsections of the
   server's data.  Alternatively, the server may implement only one
   module that defines all available data.


If we allow to make such changes as part of a module revision, i.e.,
without creating a new module, I think we should not loose the ability
to implement both the old version and the new version.

As Balazs asked, how can the data node be a boolean and an integer at the same time?
There seem to be plenty of scenarios that cannot be implemented simultaneously by a server.
<RR> Correct, but some scenarios can be implemented. IMO we should document the type of changes where this would or would not work.

Regards,
Reshad.
<snip>