NOTE: Comments Due by 20 OCTOBER 2017.

...

Alex Vul - Define what the "modeling team" is. Based on the community bylaws, we have Subcommittees and Projects. Where does the "modeling team" fit in?

maopeng zhang - Because modeling is not full or completely designed by the use cases and architecture,  I think the requirement of modeling may consider coming from the projects in implication phrase as well.

6-   Actively pursue participation from stakeholder projects in the modeling effort.

...

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.

...

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.