search

Open-Network-Models-and-Interfaces-ONMI / TAPI

LF ONMI Transport API Repository (TAPI)
https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/wiki
Apache License 2.0
95 stars 80 forks source link

Identification of "intent" modeling items #432

Closed amazzini closed 5 months ago

amazzini commented 5 years ago

Considering the attributes with complex data types (including the reference by value to other classes), how to code them into the name-value pairs of e.g. object creation notifications? It is proposed to fill the “value” string with the JSON dump of the complex type. This solution anyway opens some further considerations, e.g. in case of object creation notification of a ConnectivityService instance. ConnectivityService class has a number of composed classes: CSEP, TopologyConstraint, ResilienceConstraint, RoutingConstraint, ConnectivityConstraint. In theory, all these ancillary object instances shall be dumped into ConnectivityService Creation Notification parameters (or as result of "get" ConnectivityService). But e.g. "_corouteInclusion", refers to a ConnectivityService, which may be no longer existing. In general, it seems necessary to identify "intent" items, which may be meaningful only at provisioning time. Maybe is only necessary to have UUIDs for all the references to instances that may disappear during ConnectivityService lifecycle.

amazzini commented 5 months ago

This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.