Open-Network-Models-and-Interfaces-ONMI
YANG Backward Compatibility
TAPI 2.0 YANG model is not backward compatible with TAPI 1.0 YANG model
As outline in section 10 of https://tools.ietf.org/html/rfc6020:
As experience is gained with a module, it may be desirable to revise that module. However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification.
This is not the case: a client using TAPI 1.0 YANG would not be able to talk with a server using TAPI 2.0 YANG
Some considerations about backward compatibility needs to be provided before TAPI 2.0 can be released
TAPI 1.0 and TAPI 2.0 YANG namespaces are different
TAPI 1.0 YANG namespace:
namespace "urn:onf:params:xml:ns:yang:Tapi";
TAPI 2.0 YANG namespace:
namespace "urn:onf:params:xml:ns:yang:TapiCommon";
@italobusi apart of changes in namespaces there are some structural changes to models themselves. I guess as people are doing more TAPI based development we should start thinking about long term strategy on making models compliant. Please take in mind that TAPI models are generated from UML so potentially any UML change is backward incompatible.
IISOMI UML to YANG Mapping call April 18: Backward compatibility needs to be defined in the UML and UML-YANG mapping guidelines.
RFC7950 states in section 11: “… changes to published modules are not allowed if they have any potential to cause interoperability problems …”. Section 11 lists also the ways in which definitions from a published module may be revised. Since it is not easy to determine which kind of change violates the backward compatibility, the updated UML and YANG versions should describe the changes in detail.
Backward Compatibility should be defined in a White Paper.
Proposed rule: If it is possible to write an XSLT transformation to go from a previous version to a new version, we can claim that it is backward compatible otherwise not; i.e., changes in the representation of information are backward compatible but not semantic changes.
Question: Is e.g. the change of a unit backward compatible? E.g., from Kbits/s to Mbits/s? It is clearly possible to write a transformation rule for this.
During the IISOMI UML to YANG Mapping call April 18, I have understood that the YANG models in different TAPI releases are not aligned with the guidelines of section 11 of RFC7950 and that the plan is to follow a different approach to be defined in a White Paper
Is my understanding correct?
Please see https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools/issues/293
Hi all,
I think we should review this topic. It is not clear to me which is the official possitioning about backward compatibility in TAPI right now.
IMHO future releases of TAPI should reviwe the way how now the models are modified right now from release to release, and impose a more strict and formal process about which changes in the model are accepted or not.
My opinion is aligned with @italobusi about that TAPI would need to assume the guidelines of section 11 of RFC7950 about model changes, and also with @bzeuner: "backward compatibility needs to be defined in the UML and UML-YANG mapping guidelines."
As general comment I would recommend that we would include this topic in the meetings agenda to be discussed after the closure of current release (2.1).
This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.
