Why there are differences between the yang model capabilities receive in the Netconf hello message and Opendaylight?

Question

I've been trying to manage a device using the Restconf northbound interface of Opendaylight Oxigen and the Netconf southbound connected to a device that is running Netopeer with several yang data models.

Basically, i'm following this tutorial:

https://docs.opendaylight.org/projects/netconf/en/latest/user-guide.html#spawning-new-netconf-connectors

The issue is that there is a difference between the yang capabilities of the hello message and the obtained with Opendaylight methods.

With the hello message (ssh to the port that is running the netconf process):

<hello
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
        <capability>urn:ietf:params:netconf:base:1.0</capability>
        <capability>urn:ietf:params:netconf:base:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&amp;also-supported=report-all,report-all-tagged,trim,explicit</capability>
        <capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-yang-metadata?module=ietf-yang-metadata&amp;revision=2016-08-05</capability>
        <capability>urn:ietf:params:xml:ns:yang:1?module=yang&amp;revision=2017-02-20</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&amp;revision=2013-07-15</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&amp;revision=2013-07-15</capability>
        <capability>urn:ietf:params:netconf:capability:yang-library:1.0?revision=2018-01-17&amp;module-set-id=28</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf-acm&amp;revision=2018-02-14</capability>
        <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&amp;revision=2011-06-01&amp;features=writable-running,candidate,rollback-on-error,validate,startup,xpath</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&amp;revision=2012-02-06</capability>
        <capability>urn:ietf:params:xml:ns:netconf:notification:1.0?module=notifications&amp;revision=2008-07-14</capability>
        <capability>urn:ietf:params:xml:ns:netmod:notification?module=nc-notifications&amp;revision=2008-07-14</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name?module=ietf-x509-cert-to-name&amp;revision=2014-12-10</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf-with-defaults&amp;revision=2011-06-01</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&amp;revision=2010-10-04</capability>
        <capability>urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-hash&amp;revision=2014-08-06</capability>
        <capability>urn:ietf:params:xml:ns:yang:ietf-system?module=ietf-system&amp;revision=2014-08-06&amp;features=authentication,local-users</capability>
        <capability>urn:ietf:params:xml:ns:yang:iana-if-type?module=iana-if-type&amp;revision=2014-05-08</capability>
        <capability>urn:ieee:std:802.1Q:yang:ieee802-dot1q-types?module=ieee802-dot1q-types&amp;revision=2018-03-07</capability>
        <capability>urn:ieee:std:802.1Q:yang:ieee802-dot1q-preemption?module=ieee802-dot1q-preemption&amp;revision=2018-09-10</capability>
        <capability>urn:ieee:std:802.1Q:yang:ieee802-dot1q-sched?module=ieee802-dot1q-sched&amp;revision=2018-09-10&amp;features=scheduled-traffic</capability>
        <capability>urn:ieee:std:802.1Q:yang:ieee802-types?module=ieee802-types&amp;revision=2018-03-07</capability>
        <capability>urn:ieee:std:802.1Q:yang:ieee802-dot1q-bridge?module=ieee802-dot1q-bridge&amp;revision=2018-03-07</capability>
    </capabilities>
    <session-id>4</session-id></hello>]]>]]>

With the opendaylight restconf northbound message:

GET http://device-ip:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/TSN-Switch/yang-ext:mount/

{
    "ietf-netconf-server:netconf-server": {
        "listen": {
            "endpoint": [
                {
                    "name": "all-interfaces",
                    "ssh": {
                        "address": "0.0.0.0",
                        "port": 830,
                        "host-keys": {
                            "host-key": [
                                {
                                    "name": "imported SSH key",
                                    "public-key": "ssh_host_rsa_key"
                                }
                            ]
                        }
                    }
                },
                {
                    "name": "test_tls_listen_endpt",
                    "tls": {
                        "address": "0.0.0.0",
                        "port": 6513,
                        "client-auth": {
                            "trusted-ca-certs": "test_trusted_ca_list",
                            "cert-maps": {
                                "cert-to-name": [
                                    {
                                        "id": 1,
                                        "map-type": "ietf-x509-cert-to-name:specified",
                                        "name": "test",
                                        "fingerprint": ""
                                    }
                                ]
                            }
                        },
                        "certificates": {
                            "certificate": [
                                {
                                    "name": "test_server_cert"
                                }
                            ]
                        }
                    }
                }
            ]
        }
    },
    "ietf-keystore:keystore": {
        "private-keys": {
            "private-key": [
                {
                    "name": "test_server_key",
                    "certificate-chains": {
                        "certificate-chain": [
                            {
                                "name": "test_server_cert",
                                "certificate": [
                                    ""
                                ]
                            }
                        ]
                    }
                },
                {
                    "name": "ssh_host_rsa_key"
                }
            ]
        },
        "trusted-certificates": [
            {
                "name": "test_trusted_ca_list",
                "trusted-certificate": [
                    {
                        "name": "test_ca",
                        "certificate": ""
                    }
                ]
            }
        ]
    }
}

As you can see, the capabilities in the hello message are more and do not include the ones that are appearing in the message obtained in opendaylight.

Additionally, I checked into the yang datamodel repository of the device and found the following:

• [email protected] [email protected]
  [email protected]
  [email protected] [email protected]
  [email protected]
  [email protected]
  [email protected] [email protected]
  [email protected]
  [email protected]
  [email protected] [email protected]
  [email protected]
  [email protected] internal [email protected]
  [email protected] [email protected]
  [email protected] [email protected] [email protected] [email protected]
  [email protected]

There are appearing the models of the hello message and the models listed on the Opendaylight RESTCONF procedure.

The logs of the ODL are:

2020-11-25T12:42:33,770 | WARN  | remote-connector-processing-executor-28 | NetconfDeviceCommunicator        | 384 - org.opendaylight.netconf.sal-netconf-connector - 1.7.4 | RemoteDevice{TSN-Switch}: Session terminated Session closed
2020-11-25T12:42:33,774 | WARN  | opendaylight-cluster-data-notification-dispatcher-9799 | CallhomeStatusReporter           | 400 - org.opendaylight.netconf.callhome-provider - 1.4.4 | No corresponding callhome device found - exiting.
2020-11-25T12:42:33,774 | WARN  | opendaylight-cluster-data-notification-dispatcher-9795 | CallhomeStatusReporter           | 400 - org.opendaylight.netconf.callhome-provider - 1.4.4 | No corresponding callhome device found - exiting.
2020-11-25T12:42:33,774 | WARN  | opendaylight-cluster-data-notification-dispatcher-9794 | CallhomeStatusReporter           | 400 - org.opendaylight.netconf.callhome-provider - 1.4.4 | No corresponding callhome device found - exiting.
2020-11-25T12:42:33,776 | WARN  | opendaylight-cluster-data-notification-dispatcher-9795 | CallhomeStatusReporter           | 400 - org.opendaylight.netconf.callhome-provider - 1.4.4 | No corresponding callhome device found - exiting.
2020-11-25T12:42:33,776 | WARN  | opendaylight-cluster-data-notification-dispatcher-9792 | CallhomeStatusReporter           | 400 - org.opendaylight.netconf.callhome-provider - 1.4.4 | No corresponding callhome device found - exiting.
2020-11-25T12:42:33,776 | WARN  | opendaylight-cluster-data-notification-dispatcher-9796 | CallhomeStatusReporter           | 400 - org.opendaylight.netconf.callhome-provider - 1.4.4 | No corresponding callhome device found - exiting.