...
2- Based on existing implementation and attempt to maintain backward compatibility
Alexander Vul - Backward compatibility between releases is a MUST HAVE. Simply saying that we will "attempt" it is not good enough. Modeling requires up-front end-to-end planning and a backward compatibility strategy. We must have one as well, as part of this document.
3- Keep the
...
distinction and consistency between Information model and its data model representation(s).
a) DM does not need to match exactly the IM; DM can represent the semantics of the IM
Alexander Vul - This needs to be a bit more precise. While the mapping between the names and types of the model elements and element attributes may or may not be exact, the arrangement and the hierarchy of the information model elements can be very intentional and specific, and such needs to be maintained and carried over into the data model representation. For example, the hierarchy of the IFA011 information elements and the attributes they contain is very intentional and should be preserved within the data models.
b) DM are pruned and refactored from IM
...
4- The Information Models and Data Models from this effort should be applied across ONAP projects.
Alexander Vul - We should say that the function and operation of the ONAP management platform is predicated on use of a single, common information model,
5- The modeling team should not define the feature requirements, but take requirements derived from use cases or architecture as input.
Alexander Vul - Define what the "modeling team" is. Based on the community bylaws, we have Subcommittees and Projects. Where does the "modeling team" fit in?
6- Actively pursue participation from stakeholder projects in the modeling effort.
Alexander Vul - Define what a "modeling effort" is. Again, we have Subcommittees and Projects. Where does a "modeling effort" fit in? Observation - modeling is not an effort. Its a necessary part of building complex distributed systems. When we came together as a community, we had said that the Projects would be responsible for the creation of their own domain (information/data) models and/or model element applicable to them. We have also said that the Projects would coordinate with each through appropriate Subcommittees. We need to rationalize how the Modeling "team" and "effort" fit into this arrangement.
Guidelines
1- Initially focus on a Unified Information Model in UML and its TOSCA construct representation for Service and Resource
...
b) Based on the use cases, select the appropriate model terms if the one-to-one mapping is not possible.
Alexander Vul - I am still not clear on what the approach is. Are simply talking about terminology, or actual adoption/transference of information model elements from different sources into a single ONAP information model? For example a VNF descriptor can be built by taking elements of the IFA011 information together with information elements from other sources - ECOMP/others - and coalescing them into a single information model. I don't think talking about terminology is good enough.
5- Identify the gaps in either information modeling (in terms of information elements) or data model (in terms of types/constructs) we need to fulfill the functional/non-functional requirements derived from the use cases and prioritize per release.
...
6- When defining new constructs in ONAP Data model
a) Start with OASIS TOSCA Simple YAML Profile 1.2
b) Make use of OASIS TOSCA Simple YAML Profile 1.2 normative node types
c) If direct use of OASIS Simple YAML Profile 1.2 normative node types is not possible, extend/derive from existing node types or create new ones as appropriate
a) Best effort to use TOSCA Simple Profile 1.2 “normatives”
b) Best effort to extend/Derive from Simple Profile 1.2 “normatives”s if direct reference is not possible
c) Otherwise, derive directly from tosca.nodes.root
5- When defining new properties, best effort to put properties on capabilities.
Alexander Vul - We should follow TOSCA guidelines in this regard. I believe, use of properties is equally applicable to both requirements and capabilities.
7- When defining new Namespace, in order to avoid namespaces and types name types definitions collision, it is recommended that ONAP uses the rule and guidelines as described in the OASIS TOSCA Simple YAML Profile v1.2.
Alexander Vul - Use of TOSCA guidelines should not be a "recommendation" but a "given". If we want to use TOSCA for data modeling approach, we have to follow the rules.
8- Create a (class) diagram which outlines ONAP DM relationship to TOSCA Simple Profile 1.2
Alexander Vul - GENERAL OBSERVATION - we have three modeling domains in play for ONAP - development time, design time and run time. It would be good to establish some ground rules in terms of what IMs and what DM encodings are applicable at what "time". For example, are we implying that TOSCA data models are used across all three modeling domains? if not, then are there any principles and/or guidelines that establish what starting points and best practices are to be used within each domain?