Martin Bjorklund <m...@tail-f.com> writes: > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: >> On Wed, Feb 08, 2017 at 01:22:01PM -0500, Christian Hopps wrote: >> > >> > The tags in the library and the tags in a module are updated at the same >> > time and represent logically the same list of tags. Its clear this >> > happens with an RPC. It seems a lot less clear this would (or should) >> > happen if one edited only once location. >> >> I am not convinced by the design. We have lots of other resources >> where we have configured and system determined values. I do not see >> that tags are any different. > > I agree. *If* you want a config true datastructure, it should be > modified with the normal edit operations, not special RPCs. There are > several reasons for this. For example, how would your new RPCs interact > with locks? With candidate? With startup?
The point of already existing mechanisms and locks is somewhat compelling. Although this data is not very dynamic so it's hard to imagine locks coming into play, but the point is still taken. So if the user changes the tags on a module using the module path can we just indicate that it would automatically also update in the yang library list? We use a grouping that gets stamped inside a module and then we have another module define the yang library notation would we simply define the semantics in text and outside of yang? It's easy for the module grouping to refer to the yang library but the reverse is not true. > Also I am not sure it is a good idea to add configuration meta-data > that really should be common across all modules into the modules > themselves. Another approach is to keep a separate list with the > tags, indexed by modulename and revision. I don't understand what your getting at here. Are you referring to the grouping that gets used by a module author inside their module? The tags set for a given module are specific to that module only. Thanks, Chris. > /martin
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
