Open-Network-Models-and-Interfaces-ONMI
Should Connection be contained/scoped under ConnectivityService
Parent issue to resolve #115, #132
The current implementation is as per the containment hierarchy that was discussed/agreed by the TAPI design team during the TAPI IM design few months back.
At a high level TAPI Context holds 2 types of GlobalClass instances (first-class objects identified by uuid): Services and Resources. In general TAPI clients can create Service, delete Service, update Service and retrieve Service. Service represents what a TAPI client has requested from the TAPI provider. In response TAPI provider provisions/creates Resources and allows them to be retrieved by TAPI client.
While its certainly possible to scope every Resource (Topology, Path, Connection, Notification) within its corresponding Service, it was decided to decouple them for few reasons:
Support use cases where applications do not care about resources and are satisfied with service view only Support direct access to Resources (e.g. Topology, Notifications, etc) independent of the corresponding Service (e.g. VirtualNetworkService, NotificationService, etc) for resource group queries/filters, etc Flatter addressing (global/direct paths) to Resources (e.g. Topology, Notification, Path, Connection, ServiceEndPoint) which allows for specifying inter-resource dependencies/associations without having to specify the triggering Service Support easier implementation of augmentation/specification pattern Side effect of YANG/RESTConf mapping of the (PassedByValue v/s PassedByReference) discussion
