NOTE: Comments Due by 20 OCTOBER 2017.

This document specifies ONAP modeling design principles and guidelines for release 2+

Adolfo Perez-Duran: ONAP members have different degrees of familiarity with modeling terminology, SDOs and previous modeling efforts. Either expand acronyms in-line or provide a glossary.

Lingli Deng Glossary should be recommended to be part of each of the output working document for IM/DM. But not sure we need one for this one. It would be expected to be consumed by ONAP modeling designer/implementers within the modeling subcommittee.

The Principles section focuses on "what" foundations need to be followed as part of the ONAP Modeling effort, while the Guidelines section focuses on the plan for "how" to achieve the goals described in the Principles section and identifies best practices that may be applied.

Principles

1-  Requirements driven and prioritization per release

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.

Lingli Deng - Backward compatiblity is nice to have, but considering we are actually extending existing implementation in R2 to support more features, it might not be wise to be bounded with absolute "backward compatibility".

Michela Bevilacqua - backward compatibility guidelines to be progressed. What must be backward compatibility and how should be clarified .

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.
shitao li - I think for hierarchy is also may or may not , right? we need to looke at the model case by case. Alexander Vul - agree.

Lingli Deng - Thanks for the discussion, guys. I take the conclusion is not to dictate the hierarchy defined in the IM to be maintained by the DM. Thanks.

b)  DM are pruned and refactored from IM

c)  Discuss extensibility guidelines to be progressed (TBD)

Andrei Kojukhov - c) Overlaps with Guidelines part

Lingli Deng Agree. suggest to remove from the principle section.

d)  Apply IISOMI(Informal Inter-SDO Open Model Initiative) Approach (see diagram)

shitao li - what exactly is the IISOMI approach? Those materials in the figure all talk about the mapping between UML and YANG. I donot know how it can be applied for TOSCA. If there is a link to provide more information, I would like to learn more about it.  As a principle, I don't think mentioning IISOMI is appropriate. we can recommand people to understand more about IISOMI, but without a clear analysis report showing what can be provided and achieved by using IISOMI, it is realy hard to accept it as a working principle.

Andrei Kojukhov - agree that we need more socialization of IISOMI

Maopeng Zhang  - IISOMI Approach is not very clear in the ONAP community.  Regarding it as the principle is not suitable.

Lingli Deng Agree. I am also not convinced including it as part of this document as we do not understand it. Hence I suggest to keep it out.

xinhuili - our modeling architecture would be better based on implementation other than ONF spec

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,

Lingli Deng - I believe they are the same thing from different perspectives.

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.

Michela Bevilacqua - Rephrasing proposal.... (inspired by ONF WoW)

It is expected that each ONAP project team that will use (and contribute to) the IM will provide a representative to ensure that the work of the modeling in the sub-comittee meets the needs of their project.

The modeling subcomittee will be responsible to maintain the IM and any common (TOSCA) constructs in GitHub.

Lingli Deng - Suggest to add this statement to Modeling Subcommittee Charter.

Lingli Deng Suggest to keep it out, according the previous comment and discussion.

Guidelines

1- Initially focus on a Unified Information Model in UML and its TOSCA construct representation for Service and Resource

2-   Use Eclipse Papyrus as the UML modeling tool for this activity

3-   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.

4   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.

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. 

Michela Bevilacqua . I agree 

Andrei Kojukhov. I agree and I believe that 4,5 and 8 should be handled together because they have much in common

Lingli Deng - Let us rephrase it to allow for new definition from our effort. VNF descriptor is a good example.

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.

a)  Initial round should be based on SDC Data Model and OpenECOMP (ONAP) Information Model

b)   Identify existing constructs defined in other SDO specification (e.g. TOSCA NFV Profile and SOL001).

c)   Encourage efforts in other SDOs to align with ONAP IM/DM implementation with their specifications (e.g. TOSCA NFV Profile and SOL001) development.

Thinh Nguyenphu: bullet 5c: beside encourage efforts, ONAP should define it own core IM/DM models and touchpoints. This concept has been accepted among SDOs (ONF, TMF, and 3GPP).  My understanding is that each SDO has published their touchpoint specification. For ETSI NFV, https://docbox.etsi.org/ISG/NFV/Open/Publications_pdf/Specs-Reports/NFV-IFA%20024v2.1.1%20-%20GR%20-%20NFV%20IM%20External%20touchpoints.pdf. My recommendation: adding a new bullet 5d: defining the touchpoint and relations between ONAP core IM/DM with other organizations, such as ETSI NFV, TMF, ONF, 3GPP, etc.

Lingli Deng - Thanks Thinh for the suggestion. It makes sense for the long run, but I am afraid we might not have time for R2. Once we have defined a unified core IM/DM, it would be great to add it then.

6-  When defining new constructs in ONAP Data model

Alexander Vul - 

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

Andrei Kojukhov In general we need to develop a mechanism of introducing vendors proprietary extensions

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

Thinh Nguyenphu: bullet 6 (a-e):  I understand the desire and goal. However, it is not clear to me what is profile definition ONAP planning to use, such Simple YAML v1.2, TOSCA NFV Profile, or ONAP profile?  Also, how ONAP plan to reuse or extend existing NFV types which are currently defined in TOSCA NFV Profile and/or SOL001? 

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.

Thinh Nguyenphu: Agreed with Alex. I did not understand the purpose of bullet 5.

Maopeng Zhang - Could the author provide the rule coming from or reason why we regard it as a guideline?  I agree with Alex that basically we should  TOSCA guidelines if the data model is used by TOSCA. 

Lingli Deng - Suggest to keep it out, if no clarifications is agreed.

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.
shitao li - agree

Thinh Nguyenphu: perhaps, the change should be: 

When defining new Namespace, in order to avoid namespaces and types name types definitions collision, it is recommended that ONAP follows uses the rule and guidelines as described in the OASIS TOSCA Simple YAML Profile v1.2.

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?

Lingli Deng - My understanding, we will have IM for design time and run time. We will have UML representation for both times. We will have TOSCA representation for information exchanges across times or across modules whenever needed.