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

[Ladislav Lhotka <lhotka at cesnet.cz>]

Juergen Schoenwaelder píše v Pá 06. 11. 2009 v 17:43 +0100:
> 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.

I am just trying to understand what the acceptable (and likely) paths
are for module evolution, perhaps without the need for giving an exact
revision number.

The change of a leaf definition from mandatory=true to (mandatory=false
& new default definition) seems a natural way for establishing a data
model default based on operational experience, and it shouldn't cause
any serious interoperability problems. The change of the existing
default value is a different story though.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C