...

•Identify all the types/constructs we need

• [Munish Agarwal] Identify GAPs  and prioritize per release

• Thinh Nguyenphu (Unlicensed)] beside gaps and priority, the guideline should identify supporting features. For example, scaling feature can a simple scaling to a more complex scale such as aspect scaling to scaling to a specific level, etc. A similar different to deployment flavour too. Describing use case is important.
  

   -Initial round should be based on SDC DM and OpenECOMP (

...

[Munish Agarwal] Not relevant in the guidelines section. Consider moving to Principles)  Thinh Nguyenphu (Unlicensed): agreed with the comment

  -Identify existing construct defined in SOL001 and TOSCA NFV Profile

  -Propose new constructs to TOSCA NFV profile when desired types are not defined (

...

[Munish Agarwal] It would be good to define extensions to SOL001. VNF vendors will provide TOSCA VNFD compliant to SOL001. The new constructs in ONAP can be proposed in ETSI SOL001). Thinh Nguyenphu (Unlicensed): agreed with the comment

Munish Agarwal] Identify DM for VNFD based on the SDC DM, eCOMP IM and NFV SOL001 (IFA011)

Munish Agarwal] Identify DM for NSD based on the eCOMP  IM and NFV SOL001 (IFA014)

•Try to maintain backward compatibility

Munish Agarwal] The APIs should be backward compatible. 

Munish Agarwal] Backward compatibility guidelines on API need to be defined.

Munish Agarwal] Define UML modelling guidelines. Take inspiration from IISOMI 514 UML Modeling Guidelines

•Create a (class) diagram which outlines ONAP DM relationship to TOSCA Simple Profile 1.2 ( Munish Agarwal] Not clear. Consider rephrase)
   -Follow the principals define in next slide

•Validate the model using the selected use cases

•Tools: Papyrus

• IM

  Munish Agarwal] IM Language: UML

• Munish Agarwal] Evaluate the EAGLE work done in MEF to generate APIs from the Models

 Principles:

•New constructs
   -Best effort to use TOSCA Simple Profile 1.2 “normatives”
   -Extend/Derive from Simple Profile 1.2 “normatives”s (Munish Agarwal] Using simple profile 1.2 as basis and define new constructs taking in consideration both SOL001 and TOSCA NFV profile is the proposed way forward. Is that the correct understanding. Please clarify in either case)

 
   -Derive directly from tosca.nodes.root

   -DM does not need to match exactly the IM; DM can represent the IM

 Munish Agarwal] There should be a clear distrinction between the IM (Information Model) and DM (Data Model)
   -DM are pruned and refactored from IM
   -Discuss extensibility guidelines to be progressed

•Properties
   -Best effort to put properties on capabilities (Not clear. Consider rephrase to clarify)

...