revision in xmlns support about netopeer2 HOT 6 OPEN

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

from netopeer2.

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.

from netopeer2.

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>

from netopeer2.

You should fail to load such modules, a YANG module cannot change its namespace (meaning a single module name used for 2 namespaces).

from netopeer2.

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

from netopeer2.

Like I said, this is not supported or in any way possible in YANG/NETCONF.

from netopeer2.