On Thu, Feb 8, 2018 at 12:28 AM, Martin Bjorklund <[email protected]> wrote:
> Hi, > > In the light of this discussion, I would like to clarify that my > support is for the problem of tagging *modules*, which I believe this > draft is all about. I don't think we should extend this to tagging > *nodes*; I think that requires a different mechanism. > > > If it is about tagging modules, then the draft should really explain why this is useful and provide examples of problems solved with module tags. It can be used to tag all nodes in a module the same way. This might be useful granularity for something. A vendor might also create their own protocol mechanisms to utilize the standard tag values and ignoring the rest of this draft. > /martin > > Andy > > Juergen Schoenwaelder <[email protected]> wrote: > > On Wed, Feb 07, 2018 at 02:02:55PM -0800, Andy Bierman wrote: > > > > > IMO it will be difficult to agree on the details of this draft > > > without agreeing on the problem statement first. > > > > +1 > > > > > I am interested in these tags as a new type of standard selection > filter. > > > It can be applied to data retrieval, NACM rules, YANG push subtree > > > selection, > > > and probably many more use-cases. So the problem statement > > > might be: > > > > > > There is a need for standardized mechanisms to classify YANG data > nodes > > > with tags, > > > which can be used in protocol operations to select matching data > nodes, > > > based on tag values. > > > This work includes the management and assignment of tags, and their > > > generalized use > > > within protocol operations. > > > > The I-D talks about tags for YANG _modules_, you are talking about > > tags for YANG data nodes and you seem to imply that these tags are > > associated to instance data and that they can be used in protocol > > operations. (And then I note we already have metadata that can be > > associated to instance data. And there was Andy's packages work, which > > can be seen as another way to tag collections of schema nodes.) > > > > So yes, there is a need to agree on what the problem is that is to be > > solved (and to consider how solutions fit into the framework we > > already have in place). > > > > /js > > > > -- > > 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 > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
