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

[Andy Bierman <andy at netconfcentral.com>]

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

The server most likely knows 1 revision of the module.
It will enforce the rules in that module.  If the leaf is
mandatory in the supported version, that is all that matters.

SMIv2-like CLRs to preserve backward compatibility don't
work very well in YANG.  IMO, a better implementation
strategy for the client is to construct the server's
view of the schema tree from the <hello> and avoid any
heuristics based on the CLRs in Sec. 10.  If the client
supports deviations, then the change-control rules are
totally irrelevant, since deviations don't follow any rules.

(It would help if revisions were mandatory to use.
The CLRs do not help at all for revision-less modules.
Nothing does.)

I prefer new option (d):

   c. require revision on all modules and submodules, and also require
      import and include by revision.

  d. require revision on all modules and submodules, and think about
     import-by-revision very carefully. The WG should understand how it will
     function within the IETF wrt/ all processes.  After there are specific
     recommendations for module reuse practices, then rules for import-by-revision
     may be appropriate.


> Lada
>    

Andy