Re: [netmod] Augmenting an unimplemented module

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Feb 08, 2017 at 04:11:01PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder <[e-mail]> wrote:
> > On Wed, Feb 08, 2017 at 09:06:19AM -0500, Christian Hopps wrote:
> > > 
> > > We also went with the split route with our tags draft.
> > > 
> > > https://datatracker.ietf.org/doc/draft-rtgyangdt-netmod-module-tags/
> > > 
> > > Features like deviations were not liked internally by the group. 2
> > > modules seemed like the KISS approach.
> > >
> > 
> > I wonder why your define add-tags, remove-tags, and reset-tags
> > operations given that we have generic primitives to edit datastores.
> 
> I think (hope) they mean that these operations affect only the tags in
> yang-library, not the config container 'modules-tags' in the module
> itself.
> 
> But I think it would be better to only have these tags in the
> yang-library, and not in the module itself.  (In that case the rpcs
> are required).
> 
> Also, it might be useful if the module designer could tag modules
> at design time, using an extension:
> 
>   mt:module-tag "ietf:element-model";
>   mt:module-tag "vendor:native";

We should perhaps start a separate thread but I fail to see why tags
require new editing primitives. In fact, there seem to be system
supplied tags and configured tags. It is unclear whether I can remove
a system supplied tag. It is unclear what the persistence of added
tags is. If NC/RC clients can tag modules, then these tags are just
more config I would say.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>