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, > > 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: +36-70-330-7909 email: [1][email protected] > > References > > Visible links > 1. mailto:[email protected] > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- 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/>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
