Using existing frameworks vs. new ones

[jariarkko]

The charter text has these work items:

• A framework that will enable the collection, aggregation and consumption for mentioned metrics and attributes developed in the WG.
• A framework to enable incremental deployment by mapping legacy metrics, sourced from either dynamic or static data, to the new YANG models developed by the WG.

I understand the need for the second one, having that been explained to me :-)

I don't necessarily understand what the first one is, and to what extent existing YANG and management tooling already enables e.g. collection of metrics. Please clarify (or if it isn't clear that something is needed, remove).

[janlindblad]

I think the purpose with the second bullet is to set the scope of the collection to include systems that do not have on-board YANG-enabled management systems. For a many years to come, much of the low level collection will have to depend on legacy "protocols" like CLI-scraping, redfish, proprietary REST, some SNMP and whatever you use to read status from refrigerators/cooling systems. For YANG-capable systems, of course we'll use YANG-based polling or YANG-push.

The first bullet is about combining all the incoming datastreams in a transparent and meaningful way. So that auditors can see just what has been included in a particular graph. Today, pretty graphs are produced en masse, but ask one question about what it actually shows, and you'll experience the zero transparency situation.

[marisolpalmero]

refer to issue #55