...
4- The Information Models and Data Models from this effort should be applied across ONAP projects.
5- The modeling team should not define the feature requirements, but take requiremetns derived from use cases or architecture as input.
Lingli Deng Moved from the Guidelines section to here.
4- Actively pursue participation from stakeholder projects in the modeling effort.
Lingli Deng Moved from the Guidelines section to here.
Guidelines
1- Initially focus on a Unified Information Model in UML and its TOSCA construct representation for Service and Resource, with an initial focus on the Service Descriptor and VNF Descriptor.
Lingli Deng We agreed on starting with modeling on Service and Resource, but not limited to SD and VNFD. Otherwise, it would prevent us from demonstrating hybrid scenarioes (as one of the requirements stated for R2 discussion list, which is not what we intended, at least not for my case I am afraid. Since we do not own the requirement, and we are waiting for the requirements to come, I suggest that we do not add extra limitation ourselves right now.
2- Use Eclipse Papyrus as the UML modeling tool for this activity
3- The model will support the ONAP VNF Requirements (e.g. scaling) and use the VNF Requirements as input. The modeling team should not define the feature requirements, but rather Information Model support for defined requirements
Lingli Deng Moved to Principles section.
4- Actively pursue participation from stakeholder projects in the modeling effort.
Lingli Deng Moved to Principles section.
35- Recommend new item on the M3 API Freeze Checklist to identify and describe mapping of API information elements to the ONAP Unified Information Model and related Data Models.
46- Best effort to align terminology with ETSI (IFA011 and IFA014) where appropriate.
a) Establish a mapping between equivalent terms between ONAP and ETSI NFV ISG and identify the differences.
b) Based on the use cases, select the appropriate model terms if the one-to-one mapping is not possible.
57- 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.
a) Initial round should be based on SDC Data Model and OpenECOMP (ONAP) Information Model
...
c) Encourage efforts in other SDOs to align with ONAP IM/DM implementation with their specifications (e.g. TOSCA NFV Profile and SOL001) development.
68- When defining new constructs in ONAP Data model
a) Best effort to use TOSCA Simple Profile 1.2 “normatives”
...
c) Otherwise, derive directly from tosca.nodes.root
5- When defining new properties, best effort to put properties on capabilities.
79- 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.
810- Create a (class) diagram which outlines ONAP DM relationship to TOSCA Simple Profile 1.
...