...
- Slide 3 "shell object created in A&AI":
- note that mandatory fields and mandatory relationships cannot be enforced in AAI schema, if it is to allow empty shell objects as well as fully-formed objects
- those "mandatory" fields and relationships need to be enforced by the clients of AAI instead, meaning it could be distributed across many ONAP projects
- Slide 4 orchestration-status in Dublin:
- with the changes to the state names, how will the data migration be handled for operators upgrading to Dublin from previous releases?
- is there any forwards-compatibility or backwards-compatibility?
- Slide 5 service-instance schema in AAI:
- there are currently no substantive differences between Casablanca (v14) and Dublin (v15)
- Slides 7, 8, 10 mappings from TMF 638, TMF 641, ETSI SOL 005:
- would it be better to create a "state-mapping" class in AAI that can show explicitly the mapping to ONAP orchestration-status?
- the "state-mapping" object can be related to the service-instance object and queries can be performed using both the ONAP-native status or the external-standards-native status
- Slides 11 and 12 updates to AAI:
- seem OK