NOTE: Comments Due by 20 OCTOBER 2017.

...

Michela Bevilacqua . I agree 

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

...

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.

6-  When defining new constructs in ONAP Data model

...

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.

...

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.