Re: [netmod] instance data new backward compatibility text

[Balázs Lengyel <[e-mail]>]

Hello Jurgen,

I don't think these rules are Ericsson specific. In some of our most important use-cases (UC1, UC2, UC6) changing the keys would lead to problems.

UC1: If you document server capabilities using ietf-yang-library the name of the module sets may be/should be meaningful. It might be used by the NMS to compare the capabilities of different versions of the YANG server; changing keys without a reason will mislead the NMS into assuming the server capabilities changed..

UC2: Preloading default configuration data. E.g.  If you change the identifier of NACM ruleset, then during upgrade it might be loaded again as the server can not detect, that this is the same ruleset that is already in the datastore.

UC6:  Storing diagnostics data. If you change the keys used in diagnostic data, comparing values before and after the key change will be difficult.

And yes as we were using instance data for the last then years, we did have a lot of problem with people changing the keys without considering compatibility effects.
I agree that this is not always a problem, so I only used SHOULD  (and not MUST) in the text.

regards Balazs

On 2019. 03. 25. 23:16, Juergen Schoenwaelder wrote:

On Mon, Mar 25, 2019 at 09:59:43PM +0000, Balázs Lengyel wrote:

Hello Jurgen,

You are right that this is important mostly for instance data prepared as a
design/implementation activity; while not relevant for data coming from the
node.
I will add it.

However in the first case it is vital!

For config files, and also for file documenting server capabilities we have
had MANY problems with people changing the key values/identities of list
entries.
They think it is a nice idea to provide better, more meaningful key values;
however the NMS designers use these key values to detect changes; also
during an upgrade process if a default configuration file is loaded again
with slightly changed key values, then e.g. access control rules become
duplicated.

The conditions under which it is meaningful to change keys and when it
is not appropriate are very application specific.  You may have
specific use cases at Ericsson where you want internal regulations but
I do not think this leads to meaningful rules outside your specific
application scenario.

/js

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]