Re: [netmod] yang-08: changing a default

[Martin Bjorklund <mbj at tail-f.com>]

Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de> wrote:
> On Thu, Nov 05, 2009 at 09:43:22PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de> wrote:
> > > On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote:
> > >  
> > > > Ok, so an alternative could be this:
> > > > 
> > > >   A "default" statement can be added to a leaf that does not have a
> > > >   default value (either directly or indirectly through its type).
> > > > 
> > > > Do we agree that a default cannot be modified?
> > > 
> > > Can someone remind me what the rationale is? Adding a default
> > > statement causes an implementation that happens not to use the default
> > > value to be non-compliant. We get the same effect if someone changes a
> > > default value.
> > 
> > When a client creates say a list entry, it may choose to not give
> > values for leafs with defaults for the following reasons:
> > 
> >   1. it doesn't care about the leaf; it trusts the server to use a
> >      good default value.
> >   2. the default specified in the data model is the value it wants, so
> >      there is no need to send it.
> > 
> > If we just want to support case 1, but not 2, then we can allow any
> > changes to defaults.  If we want to support 2, we have threea options:
> > 
> >   a. do not allow addition or change of default
> >   b. do not allow changes to default, but allow addition
> >   c. require revision on all modules and submodules, and also require
> >      import and include by revision.
> > 
> > I think we have already discussed (c) and decided that it won't work.
> > (a) is what is in -08, but is probably too restrictive, and (b) is
> > the proposed text above.
> 
> So the argument is that adding a default is OK since there was none
> before and fielded client applications thus can't rely on a specific
> value. But even then, if a new client is written for the module
> version that includes the default and it talks to an old server
> predating the module revision with the default, things might break.
> You will likely response that a client must be aware of the different
> versions of a data model.

This was never a use case we tried to handle.  If the client only
knows about the new data model, it might try to set leafs which don't
even exist on the server (since you are allowed to add leafs and other
nodes), (and more...)

> From a practical perspective, I am concerned that we will see objects
> that have a default that turns out to be a bad choice after a few
> years and there is no way to fix this.

To solve this, it seems we need to require revisions, and
import/include by revision, but then...

> And I also fear that we will
> have clients that won't track all changes of data model revisions.

... clients that don't track revisions won't work well.

So what is your suggestion?


/martin