The use case described in the document is that client A tags nodes and
client B consumes the tags, i.e., two management applications
coordinate their work via tags set on the server's data tree. I am not
sure who orchestrates management applications in this way but those
who do likely do not expect interoperability on the level of the tags
since there is likely additional behaviour implied by setting tags.

If the idea is to standardize general metric tags for documentation or
lookup purposes (or some other yet to be defined purposes), then what
may appear to be simple task may turn out to be much more complex once
you dive into the details what tags really mean. There is a large body
of work on metrics that has been done in the Benchmarking Methodology
WG (bmwg). Work aiming to define a registry of tags for metrics should
surely be reviewed by bmwg people. There is also RFC 8911 produced by
IPPM, which seems to overlap with this effort to define a metrics
registry. Perhaps the whole metrics registry work needs more thought
and cross WG review and it may make sense to move it to a separate
document.

/js

On Fri, Aug 04, 2023 at 04:13:50PM +0000, tom petch wrote:
> From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen 
> <kent+i...@watsen.net>
> Sent: 19 April 2023 02:59
> 
> This email begins a two-week WGLC on:
> 
>         https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
> 
> Please take time to review this draft and post comments by May 2nd.  
> Favorable comments are especially welcomed.
> <tp>
> I think that this is a bad idea.  It lacks a coherent taxonomy, a bit like 
> setting up a relational database without first considering what classes there 
> will be, what inheritance there is and so on.
> 
> It seems to be an ad-hoc collection of categories that are of interest to the 
> authors and are likely to be meaningless in practice in the internet at 
> large.  It should look at what aspects of management it covers and then the 
> data related to each and the provide usable criteria to determine into which 
> category a data item falls.  This is substantial work, but then so is setting 
> up a usable relational database and I see enough of those where the thought 
> has not been put in on the underlying concepts, principles and so have proved 
> more of a hindrance than a help.
> 
> Tom Petch  
> 
> 
> 
> 
> This draft went through a WGLC a year ago.  The authors addressed the 
> comments received and have been were waiting for feedback.   In essence, this 
> draft is presumed to reflect WG consensus and thusly, if no objection is 
> received, the draft will move to the next step in the publication process.
> 
> Ref: https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/
> 
> Kent  // co-chair
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://constructor.university/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to