As you can see, both modules have the same namespace definition. Is this allowed?
The RFC7950 says:
5.3. XML Namespaces
All YANG definitions are specified within a module. Each module is
bound to a distinct XML namespace [XML-NAMES], which is a globally
unique URI [RFC3986]. A NETCONF client or server uses the namespace
during XML encoding of data.
This seems to be saying that namespaces must be unique per module and my schema is not adhering to this.
The reason I ask is because a client user of the Confd server is using Opendaylight to parse/import this schema and getting an error:
{code}org.opendaylight.yangtools.yang.parser.spi.source.SourceException: Module namespace collision: urn:rdns:com:ericsson:yalrt:ann
{code}
Confd is not complaining about this though.
Is Opendaylight too strict ? Or is Confd too lenient ?
ConfD does require that the namespace of all loaded modules (i.e. .fxs files) is globally unique, but based on the names of your modules, I’m guessing that they are “annotation modules” used with the -a / --annotate option to confdc when compiling the module-to-be-annotated. Annotation modules are normally not compiled and loaded “themselves”, but if you try that, you should find that ConfD notices the non-unique namespace - in current versions, it doesn’t consider this an error, but just logs a message that a .fxs file was skipped due to “namespace already loaded”.
The concept of annotation modules that aren’t actually used as such at runtime, and in fact even the concept of annotations itself, is a tail-f proprietary feature, and as such not covered by the standard specification.
As to your problem (and assuming that my guess above is correct): how did the Opendaylight code “get hold of” these modules? They can’t possibly have downloaded both of them from the ConfD server via the get-schema rpc in ietf-netconf-monitoring.yang or the like. If you are providing them by some other means, you could just exclude the annotation modules - Opendaylight isn’t likely to “understand” the tail-f annotations anyway.
Hi,
Yes, the problem was that indeed that these 2 modules are annotation modules which as you point out should not be provided to Opendaylight at all. I had provided them as a file set with the other modules because the client had not yet implemented get-schema.
I will remove them from the set. Once the client has implemented get-schema then this will not occur anymore.