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

[Andy Bierman <andy at netconfcentral.com>]

Juergen Schoenwaelder wrote:
> 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.
> 

I don't really care about this CLR, except...

What about defaults in shared typedefs?
It seems like these can never be added,
because it will set the default for any leaf
already using that typedef (if the leaf does
not yet have one.)

So even if the leaf is 'protected' by import-by-revision,
a default cannot be added to the leaf without
cut-and-pasting the 'old' typedef contents into
the leaf, replacing the typedef usage.
I want to discourage cut-and-paste reuse.

The client will get confused if the shared
typedef adds a default, and the client ignores
the revisions advertised by the server.

The client will get confused if the shared
typedef adds a default, and the client ignores
the import-revision-dates in the modules
advertised by the server.

Is there a CLR that says a default can never be
added to a typedef?  I don't think so.
If not, then the CLR for the leaf-stmt seems pointless.


> /js
> 

Andy