On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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.
> 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.
> 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 understand the transformation approach (am have implemented something
like it).
This only works if the mapping is complete. If there are any holes in the
mapping
then the affected nodes are lost. Vendors have already proven they
can implement this approach without any new standards.
Vendors are already releasing updates to old module revisions by managing
the revision date.
I agree SEMVER is incrementally better than that.
I do not agree that more than 1 revision of a module can be implemented.
A server can have multiple "outside" schema that gets transformed to the
real "inside" schema.
This is fine and breaks no YANG rules. It also requires no additional
standards unless the
transformation mechanism is going to be standardized.
> /js
>
Andy
>
> --
> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
