Does netopeer2 send a notification, yang-library-update, when a module is removed/disabled in sysrepo?

[mpet]

Hi,

We need to test this RFC:

https://datatracker.ietf.org/doc/rfc8525/

Before I create a test case I wonder if the following scenario is supported in Netopeer2:

Our NETCONF client have an open session to netopeer2 and we make a change on the module ( remove or disable) in sysrepo.
Client wait for a notifcation, yang-library-update, and when notifcation is received we read data from yang-library module again.

These are the modules:

# sysrepoctl --list
Sysrepo repository: /etc/sysrepo

Module Name                | Revision   | Flags | Owner     | Permissions | Submodules | Features
----------------------------------------------------------------------------------------------------------------------------------------------------------------
iana-crypt-hash            | 2014-08-06 | i     |           |             |            |
ietf-crypto-types          | 2019-07-02 | I     | root:root | 600         |            |
ietf-datastores            | 2018-02-14 | I     | root:root | 600         |            |
ietf-inet-types            | 2013-07-15 | i     |           |             |            |
ietf-keystore              | 2019-07-02 | I     | root:root | 600         |            | keystore-supported
ietf-netconf               | 2013-09-29 | I     | root:root | 600         |            | writable-running candidate rollback-on-error validate startup url xpath
ietf-netconf-acm           | 2018-02-14 | I     | root:root | 600         |            |
ietf-netconf-monitoring    | 2010-10-04 | I     | root:root | 600         |            |
ietf-netconf-nmda          | 2019-01-07 | I     | root:root | 600         |            | origin with-defaults
ietf-netconf-notifications | 2012-02-06 | I     | root:root | 600         |            |
ietf-netconf-server        | 2019-07-02 | I     | root:root | 600         |            | ssh-listen tls-listen ssh-call-home tls-call-home
ietf-netconf-with-defaults | 2011-06-01 | I     | root:root | 600         |            |
ietf-origin                | 2018-02-14 | I     | root:root | 600         |            |
ietf-ssh-common            | 2019-07-02 | i     |           |             |            |
ietf-ssh-server            | 2019-07-02 | I     | root:root | 600         |            | local-client-auth-supported
ietf-tcp-client            | 2019-07-02 | i     |           |             |            |
ietf-tcp-common            | 2019-07-02 | I     | root:root | 600         |            | keepalives-supported
ietf-tcp-server            | 2019-07-02 | i     |           |             |            |
ietf-tls-common            | 2019-07-02 | i     |           |             |            |
ietf-tls-server            | 2019-07-02 | I     | root:root | 600         |            | local-client-auth-supported
ietf-truststore            | 2019-07-02 | I     | root:root | 600         |            | truststore-supported x509-certificates
ietf-x509-cert-to-name     | 2014-12-10 | I     | root:root | 600         |            |
ietf-yang-library          | 2019-01-04 | I     | root:root | 600         |            |
ietf-yang-metadata         | 2016-08-05 | i     |           |             |            |
ietf-yang-types            | 2013-07-15 | i     |           |             |            |
nc-notifications           | 2008-07-14 | I     | root:root | 600         |            |
notifications              | 2008-07-14 | I     | root:root | 600         |            |
sysrepo-monitoring         | 2021-01-15 | I     | root:root | 600         |            |
sysrepo-plugind            | 2020-12-10 | I     | root:root | 600         |            |
yang                       | 2017-02-20 | I     | root:root | 600         |            |

Flags meaning: I - Installed/i - Imported; R - Replay support; N - New/X - Removed/U - Updated; F - Feature changes
Features: ! - Means that the feature is effectively disabled because of its false if-feature(s)

1. Which operation, remove or disable, module in sysrepo is easiest to perfom and restore?
   1.1 Any of these modules that I can perform remove or disable on without giving netopeer2 issues?
   1.2 Commands to use ?

2. Will a notifcation, yang-library-update, be sent in the same NETCONF session ( I have a subscription ongoing for that NETCONF session) to client when module change takes place?

br,

//mikael

Operations in sys-repo:

https://netopeer.liberouter.org/doc/sysrepo/master/html/group__schema__api.html#ga7321be6b965ffc6ca89fee61a806faae

https://netopeer.liberouter.org/doc/sysrepo/master/html/group__schema__api.html#ga7793eebc32a87bc48b340030cde5042c

[michalvasko]

1. Makes no difference, they are simple to perform and revert.
   1.1. These are all the default server modules so you should not be uninstalling any of those.
   1.2. You can use sysrepoctl to perform any YANG modules changes.

2. No, updating the supported YANG modules in a running NETCONF session is not a supported use-case by NETCONF, it is not mentioned anywhere. And as long as there is a NETCONF session, the server is holding the YANG context lock and any YANG modules changes will fail on a timeout because of this. So no, the session will not get any notification.

   I suppose it could be improved to support this, to some extent. It would be possible to implement some internal mechanism of informing about context changes that results in the server updating its context and sending the mentioned notification to all the connected sessions. They could then restart their connection to have the updated context, there is no simple and direct way of doing so without a connection restart (would again have to be some proprietary design and solution). If they don't, they would continue to use the old context, should already be properly handled.

[mpet]

2. Yes I think that is the point of the notification to inform and then we can check yang-lib module info about the change and close session and perform a new connection.

[mpet]

Also just double checking:
And there will be no netconf-capability-change notification when the module is changed?

[michalvasko]

Right, that can be sent, too. Although it seems to be redundant, the 2 notifications would essentially include the same information.

[mpet]

@michalvasko and I guess that there is no difference if we use adding a module?

[michalvasko]

I do not understand the question, difference between what?