ONAP Modeling Design Principles and Guidelines Open Issues

1, Modeling Glossary

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

2, Backward Compatiblity Guidelines

@Alex 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, Apply IISOMI(Informal Inter-SDO Open Model Initiative) Approach

@lishitao - 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.

@andreik - 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.

@Former user (Deleted) - our modeling architecture would be better based on implementation other than ONF spec

4, Touch points with other SDOs

@Thinh Nguyenphu (Unlicensed): 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.

5, Allow for proprietary extensions for DM

@andreik In general we need to develop a mechanism of introducing vendors proprietary extensions

6, When defining new properties, best effort to put properties on capabilities.

@Alex Vul - We should follow TOSCA guidelines in this regard. I believe, use of properties is equally applicable to both requirements and capabilities.

@Thinh Nguyenphu (Unlicensed): 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, Domain Specific Guidelines

@Alex 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.