implement ietf-system-capabilities and ietf-notification-capabilities

[jeremie6wind]

This patch is an implementation of RFC9696
Link: https://datatracker.ietf.org/doc/html/rfc9196

netopeer2 can return the operational data of /ietf-system-capabilities:system-capabilities
which contains the limit values of several parameters.

max-nodes-per-update: there is no limit on the number of node to send inside a notif in sysrepo. The max unsigned integer value is set.
periodic-notifications-supported and on-change-supported: The publisher is capable of sending notifications for 'config false' and 'config true' nodes.
minimum-update-period and minimum-dampening-period: The minimum value is 0.
supported-excluded-change-type: All types of changes can be excluded.

A sysrepocfg command would give this result:

# sysrepocfg -f json -x "/ietf-system-capabilities:system-capabilities" -v2 -X -d operational

{
  "ietf-system-capabilities:system-capabilities": {
    "datastore-capabilities": [
      {
        "datastore": "ietf-datastores:startup",
        "per-node-capabilities": [
          {
            "ietf-notification-capabilities:subscription-capabilities": {
              "max-nodes-per-update": 4294967295,
              "periodic-notifications-supported": "config-changes state-changes",
              "minimum-update-period": 0,
              "on-change-supported": "config-changes state-changes",
              "minimum-dampening-period": 0,
              "supported-excluded-change-type": [
                "all"
              ]
            }
          }
        ]
      },
      {
        "datastore": "ietf-datastores:running",
        "per-node-capabilities": [
          {
            "ietf-notification-capabilities:subscription-capabilities": {
              "max-nodes-per-update": 4294967295,
              "periodic-notifications-supported": "config-changes state-changes",
              "minimum-update-period": 0,
              "on-change-supported": "config-changes state-changes",
              "minimum-dampening-period": 0,
              "supported-excluded-change-type": [
                "all"
              ]
            }
          }
        ]
      },
      {
        "datastore": "ietf-datastores:candidate",
        "per-node-capabilities": [
          {
            "ietf-notification-capabilities:subscription-capabilities": {
              "max-nodes-per-update": 4294967295,
              "periodic-notifications-supported": "config-changes state-changes",
              "minimum-update-period": 0,
              "on-change-supported": "config-changes state-changes",
              "minimum-dampening-period": 0,
              "supported-excluded-change-type": [
                "all"
              ]
            }
          }
        ]
      },
      {
        "datastore": "ietf-datastores:operational",
        "per-node-capabilities": [
          {
            "ietf-notification-capabilities:subscription-capabilities": {
              "max-nodes-per-update": 4294967295,
              "periodic-notifications-supported": "config-changes state-changes",
              "minimum-update-period": 0,
              "on-change-supported": "config-changes state-changes",
              "minimum-dampening-period": 0,
              "supported-excluded-change-type": [
                "all"
              ]
            }
          }
        ]
      }
    ],
    "ietf-notification-capabilities:subscription-capabilities": {
      "max-nodes-per-update": 4294967295,
      "periodic-notifications-supported": "config-changes state-changes",
      "minimum-update-period": 0,
      "on-change-supported": "config-changes state-changes",
      "minimum-dampening-period": 0,
      "supported-excluded-change-type": [
        "all"
      ]
    }
  }
}

[michalvasko]

Okay, no problem, just do a minor refactoring and it should be good to go.

[jktjkt]

periodic-notifications-supported and on-change-supported: The publisher is capable of sending notifications for 'config false' and 'config true' nodes.
minimum-update-period and minimum-dampening-period: The minimum value is 0.

When these fields are implemented, IMHO there's an expectation that the entire device (as visible over, say, NETCONF) will adhere to this behavior and send the updates based on the advertised intervals. But in case of sysrepo, I think this really depends on the way how your application-level CBs are set up -- isn't it? In that case, is it a good idea to possibly advertise features which are not met by the rest of the system?

[jeremie6wind]

Hi,
thank you for your feedback.

I agree that the subscriptions set up defines the behavior of the notifications.
The idea here is to put default values for the fields.
For example, it is possible to configure 0 as the notification period for example, if nothing is implemented.
Other applications can subscribe to provide operational data and overwrite the values(define per node values)
according to the device capabilities thanks to the merge flag.
Would you prefer the content without the periods? without periodic-notifications-supported and on-change-supported?
Thanks