Subject: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"

From: IETF Secretariat <[email-masked]>
Date: Sun, 26 Jul 2020 06:56:17 -0700

The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state
Candidate for WG Adoption (entered by Lou Berger)

The document is available at
https://datatracker.ietf.org/doc/draft-tao-netmod-yang-node-tags/

Comment:
IPR disclosures:
https://datatracker.ietf.org/ipr/4216/
Mail poll:
https://mailarchive.ietf.org/arch/msg/netmod/pyk2fLkG8srCuZKg7dDI3ypzKrQ/

Liang Geng:
https://mailarchive.ietf.org/arch/msg/netmod/rXb-ZeXzvCQAByu2fFJlbno6tR4/ Du
Zongpeng:
https://mailarchive.ietf.org/arch/msg/netmod/PRfcKZjjttBO4l3hW2VwEKwXJmc/ Ran
Tao:
https://mailarchive.ietf.org/arch/msg/netmod/O54ihWu6g5dnZmkJGHVByX7hpoo/ Qin
Wu: https://mailarchive.ietf.org/arch/msg/netmod/7jdfrEj61mcF2ASE6dDP8zOHfps/
Benoit Claise:
https://mailarchive.ietf.org/arch/msg/netmod/3C-K4JaAgLnpAoPqcQAn59DFHYw/

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2020 10:48:01 +0200

I do not understand the abstract of the document. The main sentence is
this one:

   This YANG data node tagging method
   can be used to provide input, instruction, indication to selection
   filter and filter queries of operational state on a server during a
   "pub/sub" service for YANG datastore updates and provide multiple
   dimensional network visibility analysis when the state of all
   subscriptions of a particular Subscriber to be fetched is huge, so
   that the amount of data to be streamed out to the destination can be
   greatly reduced and only targeted to the characteristics data.

I can follow up to 'multiple dimensional network visibility analysis'
and then I am lost.

On the technical side, it is not clear why a central list of tags
providing meta information is preferrable over metadata annotations
that can be shipped with the values.

It does not seem harmful to adopt this work if people think this is
needed and they are willing to work on this. The others can safely
ignore this with. Personally, I am not convinced yet, but then I do
not work on 'multiple dimensional network visibility analysis'.
Perhaps a good convincing concrete example would help, the tables in
Fig. 2 do not help me much.

The goal seems to add tags to node instances. I do not understand what
they are called 'self-explanation-node-tags' and not simply
'node-tags'. It is also unclear why we need exactly those eight
different tag types. How does this relate to YANG defined properties
such as units?  If there is a mismatch, what takes precedence?

If I define tags in a module using the extension statements, why do I
also have to have these tags in the instance tree?

draft-ietf-netmod-module-tags defines module tags plus mechanisms to
tweak them if needed. This document seems to define node instance tags
but hidden in a very specific use case. I think the WG should
determine whether it wants to work on "YANG Node Instance Tags" along
the "YANG Module Tags" work. I personally find the scope of the work
behind the current document unclear.

/js

On Sun, Jul 26, 2020 at 06:56:17AM -0700, IETF Secretariat wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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/>