How command searchpath works about netopeer2 HOT 15 CLOSED

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.

from netopeer2.

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?

from netopeer2.

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.

from netopeer2.

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 ?

from netopeer2.

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.

from netopeer2.

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 ?

from netopeer2.

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

from netopeer2.

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.

from netopeer2.

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

from netopeer2.

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

from netopeer2.

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.

from netopeer2.

Thanks for clarifications, let's close the question

from netopeer2.

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.)

from netopeer2.

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.

from netopeer2.

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, [email protected] and [email protected] both existing on disk in that directory, please file a bug. This feature is (I suppose) intended to be used as a caching optimization.

from netopeer2.