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

[Ladislav Lhotka <lhotka at cesnet.cz>]

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.

Lada
   
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C