Subject: [netmod] instance data new backward compatibility text

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Mar 2019 14:19:03 +0100

Hi,

I am not sure why we have this new section. The notion of backwards
compatibility for instance data is somewhat dubious. There text that
is there now is potentially even harmful or it needs to be ignored. If
I dump datastore content into an instance file, I get what I get. The
text that is there may help with maunally edited instance files but
this is where it ends. My proposal is to simply drop section 6 again.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 25 Mar 2019 21:59:43 +0000

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.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Mar 2019 23:16:09 +0100

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

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 25 Mar 2019 23:01:52 +0000

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:

Hello Jurgen,

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Mar 2019 00:22:40 +0100

Your rules are use case specific and I am not convinced they are
applying to all use cases. It should be a perfectly valid use case to
store snapshots of <running> in instance data files. Your rules do not
make sense here and I do not think this is a valid usage of the SHOULD
mechanism.

/js

On Mon, Mar 25, 2019 at 11:01:52PM +0000, Balázs Lengyel wrote:
>    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,
> 
>  Mobile: +36-70-330-7909              email: [1][email-masked]
> 
> References
> 
>    Visible links
>    1. mailto:[email-masked]

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Mar 2019 11:53:03 +0100 (CET)

Hi

I agree with Juergen.  I think section 6 should be removed.  This
document should specify the document format (which it does), but it
shouldn't specify specific rules for the different use cases.

/martin

Juergen Schoenwaelder <[email-masked]> wrote:
> On Mon, Mar 25, 2019 at 11:01:52PM +0000, BalÃ¡zs Lengyel wrote:
> >    Hello Jurgen,
> > 
> >    UC2: Preloading default configuration data. E.g.Â If you change the
> >    UC6:Â Storing diagnostics data. If you change the keys used in diagnostic
> >    I agree that this is not always a problem, so I only used SHOULDÂ (and not
> >    MUST) in the text.
> > 
> >    regards Balazs
> > 
> > 
> >  Mobile: +36-70-330-7909              email: [1]Balazs.Lengyel@ericsson..com
> > 
> > References
> > 
> >    Visible links