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

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

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.

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. And I also fear that we will
have clients that won't track all changes of data model revisions.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>