CESNET
revision in xmlns support
With netopeer2 in Version 2.2.13, on top of embedded module ietf-crypto-types in revision 2023-12-28, we are loaded same module but in revision 2019-04-29. Seems to be properly supported by the NC Server, as both modules are displayed via sysrepoctl --list cmd, each one with its own revision. Now, at NC Client side, in a the xml payload of a rpc, we want to refer module in revision 2019-04-29 without really knowing if possible.... we have try several syntax :
<algorithm xmlns="urn:ietf:params:xml:ns:yang:ietf-crypto-types?revision=2019-04-29">secp256r1</algorithm>
<algorithm xmlns="urn:ietf:params:xml:ns:yang:ietf-crypto-types?revision=2019-04-29&module=ietf-crypto-types">secp256r1</algorithm>
But, none is working. Error returned by CLI is are the following :
user-rpc --content=/opt/dev/xml/file-download-vnr-ok.xml ly ERROR: No module with namespace "urn:yang:ietf-crypto-types?revision=2019-04-29" in the context. (Data location "/file-management:file-download/server/keys", line number 10.) nc ERROR: Failed to create RPC, perhaps a required feature is disabled. cli_send_recv: Failed to send the RPC. user-rpc --content=/opt/dev/xml/file-download-vnr-ok.xml ly ERROR: No module with namespace "urn:ietf-crypto-types?revision=2019-04-29" in the context. (Data location "/file-management:file-download/server/keys", line number 10.) nc ERROR: Failed to create RPC, perhaps a required feature is disabled. cli_send_recv: Failed to send the RPC. user-rpc --content=/opt/dev/xml/file-download-vnr-ok.xml ly ERROR: No module with namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types:2019-04-29" in the context. (Data location "/file-management:file-download/server/keys", line number 10.) nc ERROR: Failed to create RPC, perhaps a required feature is disabled. cli_send_recv: Failed to send the RPC.
Does specification of a module revision is supported in an xml payload via usage of xmlns ? It yes what is the syntax ?
It must be noted that whatever the revision of ietf-crypto-types, namespace remain the same : namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; So without model number at the end, like it could be : namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types:1.0"; So only remaining solution to map the NC Client to the targeted ietf-crypto-module of the NC Server is to use the revision
Does specification of a module revision is supported in an xml payload via usage of xmlns ?
No, it is not possible at all. There can be several revisions of a single module loaded into a YANG context but only one is implemented. This revision is then used for parsing all the data of the module. The 2023 revision must be implemented because there are features and identities. So, if you also require the 2019 revision to be implemented, you have a problem because such a context cannot be created.
Ok, understood for IETF modules embedded into Netopeer2 NC Server. But what about pure application modules, if an application has set two modules with same name, same prefix, but with different iteration of the namescape : "urn:application:1.0" and "urn:application:1.1"
Does Netopeer2 is able to map xml NETCONF payload from NC Client to each module loaded in NC Server ?
<color> xmlnx:app="urn:application:1.0">app::bleu</color>
<color> xmlnx:app="urn:application:1.1">app::bleu</color>
You should fail to load such modules, a YANG module cannot change its namespace (meaning a single module name used for 2 namespaces).
As said, in the scenario described above, there are two modules loaded in NC Server :
- application.yang in revision x having namescape "urn:application:1.0", prefix app
- application.yang in revision y having namespace "urn:application:1.1", prefix app Expectation is that NC Client can select the module to be used into the NC Server ( revision x or y ) just by declaring the proper namescape in the xml payload
Like I said, this is not supported or in any way possible in YANG/NETCONF.