...
| # | Interface | Requirement | Additional Information | Sign Off |
|---|---|---|---|---|
| 1 | CPS-E-08.e | NCMP is to merge CM Notification Subscriptions Create request for the same CM Handle & XPath(s) |
| |
| 2 | CPS-E-08.e | Last lights out: upon subscription Delete request only when there is no more subscription for a cm-handle & xpath combination a subscription-delete request wil be send to the relevant DMI(s) | ||
| 3 | CPS-E-08.e | Amalgamation per DMI: all subscription updates originating from a single client request should be send to a single DMI in one request (message). Of course there can be several message if more than 1 DMI is involved. | The need for amalgamation / granularity of message might need to be discussed pending the required characteristics (issue #8). If a single subscriptions can contain all possible cm-handles with many cps-paths it then becomes feasible all CM-Handles refuse all paths or a specific path... Will all that info fit in a single response message. Is that the right thing to do?!!! | |
| 4 | CPS-NCMP-I-01 | CM Handle deletion should update subscription details | do NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below | |
| 5 | CPS-E-08.e | backward compatible with 'basic' created/delete operations.. TBD | could use versioning in API–methods and schema's to handle this?! |
...