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

@Alex Vul (Deactivated) - 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).

@Alex Vul (Deactivated) - 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.
@lishitao - I think for hierarchy is also may or may not , right? we need to looke at the model case by case. @Alex Vul (Deactivated) - 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.