|
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. 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: balazs.leng...@ericsson.com |
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
