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 protected]> wrote: > 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
