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

On 09/11/2018 11:38, Andy Bierman wrote:
>
>
> On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder 
> <j.schoenwaelder@jacobs-university.de 
> <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
>
>     On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
>     > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de
>     <mailto:j.schoenwaelder@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.

Yes, not the same node, but both representing the same property.

For "config false", or stuff coming out of operational then I have no 
issues with two nodes reporting different representations of the same 
property (unless default values are not being returned).  This is quite 
a common thing to do anyway, and clients can ignore the data that is not 
being returned.

But I struggle to understand how have two nodes in the same schema that 
both directly manipulate the same underlying config property works.  I 
think that various folks have suggesting that this is a viable way of 
fixing bugs in config nodes, but I would be interested to see an 
explanation of exactly how this works, and what limitations are deemed 
to be acceptable.

>
>     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 that there are lots of questions if you have two properties 
representing the same underlying configurable node:
  - can they both be configured at the same time with different values?
  - can they both be configured at the same time with the same value?
  - what if the configured value for one data node is not representable 
in the other data node?
  - what if the defaults values differ?

>
>     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 the solution that I'm potentially thinking of ... but it may 
require some protocol mechanism for a client to be able to select which 
"outside" schema it is using, if the server supports multiple.

If different revisions of modules exist in different "outside" schema 
then some may argue that the server is implementing two different 
revisions of a module.

For me, one thing is certain, is that there should only be a single 
revision of each module as being implemented in YANG library.

> This is fine and breaks no YANG rules.  It also requires no additional 
> standards unless the
> transformation mechanism is going to be standardized.
>
No current plans to try and standardize the transformation mechanism.

Thanks,
Rob

>
>
>     /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/
>     <https://www.jacobs-university.de/>>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod