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

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

On Fri, Nov 06, 2009 at 06:05:53PM +0100, Ladislav Lhotka wrote:
 
> 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.

There will be defaults created with the best intentions that will be
wrong when the underlying protocol evolves. There will be must
expressions created with the best intentions that will wrong when the
underlying technology evolves. This is all fine and the answer to such
situations is to obsolete definitions and to create new ones.

The original question was why adding a default is OK while changing a
default is not.

Martin took the position that changing a default might break a
contract between a client and a server. In the case where you add a
default, you can't break a contract since there was no defined
default. This is a reasonable position.

Andy argues that clients have to know the exact version of the data
model used by a given server (and its deviations) in order to do the
right thing. And yes, this is also a defendable position - but it
means that clients have to be pretty smart and be able to deal with
many different revisions (even in a single vendor product line). This
sets the bar of relying on defaults from the client side pretty
high. So if my client happens to care of the value (means it needs a
certain value - not that it is fine with whatever default value the
server will pick), it better sets the value even if the data model
promises the same default value in its data model. In other words, I
would very likely not take any advantage of the knowledge of a default
value on a client side since doing it correctly is way more effort
that is the saving's gain.

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