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

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

On Fri, Nov 06, 2009 at 05:26:45PM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v ??t 05. 11. 2009 v 23:18 +0100: 
> > On Thu, Nov 05, 2009 at 10:15:36PM +0100, Martin Bjorklund wrote:
> > > > 
> > > > 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...)
> > 
> > OK, I admit to be undecided. But then, an attempt to create a leaf
> > that is not supported results in an error. Assuming a default that is
> > not known by the server causes surprises, and surprises are bad.
> > 
> 
> But the fact that there was no default in the old version can mean three
> things:
> 
> 1. The leaf was mandatory in the old version, so an error will be
> reported if the client doesn't set the value.
> 
> 2. The value is not used at all by the old server version, so it doesn't
> matter what the client does to it.
> 
> 3. The value is system-created by the old server version. Only this case
> can lead to an undetected mismatch between the server and client.
> 
> IMO the only scenario for a reliable module evolution is 1. The
> questions that have to be asked when the data model is being designed
> are (i) whether the given parameter is operational or configuration, and
> (ii) whether it is needed for server operation or not. If the answer to
> either of these questions changes, it is not the same data model
> anymore.

But we are not discussing config true/false here - I think I do not
understand your answer. A default on config false has little value,
except for those who like to filter default values from config false
objects, which is not my concern.

/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/>