Compatibility issues in using prefix instead of module name

[open-switch]

Compatibility issues in using prefix instead of module name

[rakeshdatta]

@kot-begemot-uk I understand you are asking to keep the yang file name and the model name (what we provide as prefix) to be the same. Plz correct me.

I am not sure why is this important. Can you please share the relevant information of this issue in terms of the bug template provided here: https://github.com/open-switch/opx-docs/wiki/Report-bugs

[kot-begemot-uk]

Nope, you did not understand me correctly. The file name has nothing to do with this.

The YANG RFCs and RFCs governing interoperable YANG DATA implementations 8040, 6241, etc ALWAYS qualify data elements with MODULE name to differentiate between data elements brought by different modules. The PREFIX has only local significance and only for the purposes of assembling they yang model. Example - if I import iana-if-type and call it prefix "iana" instead of "ianaift" in my model that is perfectly valid yang and will be compiled and loaded by every yang implementation out there. However, if the user after that tries to access data it will be presented as "iana-if-type":"ethernetCsmacd". Plenty of examples in RFC8040, starting with section 3.7 onwards.

CPS does not follow this design assumption and assigns special meaning to the PREFIX.

1. It makes it incompatible with existing models. If we pull a sample of models from any of the upstream yang repositories and look at the most commonly used import "ietf-inet-types". It is imported with 3-4 different names. This means that only the models which by "chance" have used the same prefix name as in CPS can be used. Everything else cannot be imported.

2. It makes it incompatible with any standard compliant rfc implementation necessitating a mapping shim which has to be aware of what prefix did CPS use for the particular module-name.

This is not just a bug, it is a design issue. It is broken across the board and it will only become more broken going forward as more models are added in a manner which is not compatible with anything else out there.

[kot-begemot-uk]

What is the problem you are reporting - Fundamental design fault
Do you have a use case including examples? - yes, stated
Is there a blocker? (Y/N), and include the reasoning if it is a blocker. - it is a blocker for implementing restconf, netconf or any other interop natively without presenting a "hacked" model to the consumer
OPX version that you are using (latest or specific version) - all up to head of tree
Which platform are you using? - Irrelevant as bug is on all platforms
How frequently is the bug reproducible (always, intermittently, and so on)? - Always
Include the steps to reproduce the problem - Just read the rfc please
Include any logs (journalctl -f, opx-show-version, opx-show-system-status, and so on). - not applicable
Have you found a workaround that resolves your problem? - none