search

open-switch / opx-cps

https://openswitch.net
6 stars 15 forks source link

Compatibility issues in using prefix instead of module name #72

Open kot-begemot-uk opened 6 years ago

kot-begemot-uk commented 6 years ago

The standard for a Yang Instance Identifier in yang data is different from the actual model data including YIN. Model grammar specifies: [prefix:] identifier That is fine for the model, because there is an implicit guarantee that [prefix:]identifier is locally unique and has local meaning.

Using this notation for data keys has issues for data interop.

While it is possible to map this to netconf and xml/restconf instance identifiers with the assistance of schema it will break for JSON data where the canonical form uses module-name (with optional revision qualifiers) for prefixes.

rakeshdatta commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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