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

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

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.

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

I have no good answer. Perhaps all we can do are explicit warnings
that relying on defaults that get added after the publication of an
initial revision of a YANG module requires to do proper version
checking and if an application is not able to do that, to not rely on
the default being present. And perhaps guidelines^Hwarnings to data
model designer as well that defaults are final, you won't be able to
change them ever since applications are allowed to rely on it.

The only alternative would be to go back to the SMIv2 semantics where
defaults are not binding - which means you better set them expicitely
unless you trust the device to pick something reasonable (means I do
not care what is picked).

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