How command searchpath works

[Netzo91]

Hi,

I want to clarify how the command searchpath works.

In the help it say : Set the directory, which will be used when searching for modules. Modules are always needed to be able to work with the same data as a NETCONF server. They are searched locally (in this directory) only if the server does not support the <get-schema> NETCONF operation

What does that mean? if the server supports get-schema even if modules are pointed locally by searchpath, netopeer2-cli will use those via get-schema? is there a way to bypass get-schema modules for the netopeer2-cli (without modify the server)?

Thanks in advance for your reply

[michalvasko]

Where are you reading this description? It is not up-to-date, modules are first searched locally (if the revision is known) and only if not found get-schema is used to retrieve them from the server.

[AeroFlorian]

Hi, This is directly in the code: netopeer2/cli/doc/netopeer2-cli.1 at 373eb48edaf86c5d44a5f86399d2e38f9de76bf0 · CESNET/netopeer2 (github.com)

What we want to do here is use different revisions for models on client side and server side:

Then, we want to validate that when Netconf client sends requests and gets responses they are valid with its set of Yang models (revision A) We tried sending an edit-config rpc that is valid on revision B but not valid on revision A, and netopeer2-cli sent it without checking it was valid. Same with a get rpc, the response from netopeer2-server was valid in revision B but not in revision A and netopeer2-cli received it and displayed it without checking.

The questions we have are:

• Does netopeer2-cli validate the requests/answers based on its own set of yangs?
• If not, is there a way to do the scenario we want? And what for is searchpath used?

[michalvasko]

What we want to do here is use different revisions for models on client side and server side:

No, do not do this, it is not supported, goes directly against NETCONF specs, and can cause nothing but issues.

[robbynet]

Then, if searchpath is not to check that a set of Yang in Vn at NC Client side is still backward compatible with a set of Yang at NC Server side in Vn+1, what are user scenarii where command searchpath is intended to be used ?

[michalvasko]

It is just another configuration parameter. Any modules downloaded using get-schema are stored in the search path and the next time you connect to the same server, the modules can be loaded locally. But if you already have all the modules, you can use searchpath to point to the right directory and the modules do not have to be downloaded at all, for optimization.

[robbynet]

The reality in our field is that NC Clients having a set of Yang in Vn must interoperate with other devices hosting NC Servers executed with a set of Yang in Vn+1. How is it possible to test such interoperability with the NC Client/Server components made available by Netopeer2 ?

[robbynet]

Because get-schema is not used by our real NC Client even if supported by the NC Server

[michalvasko]

How is it possible to test such interoperability with the NC Client/Server components made available by Netopeer2 ?

YANG module versioning is currently a hot topic in IETF, you are free to take part in the discussions. But as it stands, the old rules are quite simple and strict. Like I said, you must use the same set of modules on both the client and the server, nothing else is permitted and expected to work.

[robbynet]

Thanks for the sharing, now state of the art is clear.

[AeroFlorian]

Additional question: Does netopeer2-cli validates requests/responses based on their modules stored?

[michalvasko]

The CLI loads all the server modules when establishing the connection because it parses all the NETCONF messages. So yes, all the requests and responses are parsed (and validated) by libyang.

[AeroFlorian]

Thanks for clarifications, let's close the question

[jktjkt]

The reality in our field is that NC Clients having a set of Yang in Vn must interoperate with other devices hosting NC Servers executed with a set of Yang in Vn+1.

This should work just fine as long as your NETCONF servers properly bump the revision date on each change. Is that the case for your servers? (For development purposes, setting the cache directory to a throwaway location looks like a sensible step.)

[robbynet]

The reality in our field is that NC Clients having a set of Yang in Vn must interoperate with other devices hosting NC Servers executed with a set of Yang in Vn+1.

This should work just fine as long as your NETCONF servers properly bump the revision date on each change. Is that the case for your servers? (For development purposes, setting the cache directory to a throwaway location looks like a sensible step.)

Yes, O-RAN WG4 is always taking care to change revision of the module when modifications in the modules are performed.

[jktjkt]

Then you should have no problems; you can let the code slowly fill up directory with local copies of YANG files retrieved from various NETCONF servers. If you're using some SW that's using libnetconf2, and if this software has a problem with, say, example@2024-01-01.yang and example@2024-01-02.yang both existing on disk in that directory, please file a bug. This feature is (I suppose) intended to be used as a caching optimization.