...
| # | 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. | ||
| 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 |
Error Handling
| # | Error Scenario | Expected behavior | Sign-off | |
|---|---|---|---|---|
| 1 | DMI Down | rejected | ||
| 2 | DMI Not responding withing 30 sec | pending | ||
| 3 | create for non-existing cm handle id | rejected | ||
| 4 | delete for non-existing cm handle id | (silently?) ignore | ||
| 5 | any operation on non-existing xpath | ignore? (no or minimal validation, see issue #5) | ||
| 6 | error upon error | An error scenario on a second subscription for the same cm-handle/xpath as a previous subscription which did not complete successfully (yet) to be discussed, see tabel below |
Characteristics
| # | Parameter | Expectation | Notes |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 |
...
| # | Issue | Notes | Decision |
|---|---|---|---|
| 1 | Is it intended that CM Notification subscription request cover (all) descendants of the given xpath too?! | e.g.. if a child is removed and there is a subscription for the parent node, will a notification be send (grandchild, child leaf updates etc.) I hope NOT! | |
| 2 | Could xpath point to an element that does not exist (yet) | if not how, how can I client be informed about a create event? | |
| 3 | Should NCMP support re-homing, moving of a CM Handle from one DMI to another? | assume only trough delete & create | |
| 4 | CM Handle Delete: Should DMI or Clients be sent a subscription update (assume no) | do NOT delete dmi-subscription entry until owning subscription is deleted (just ignore upon future delete if cm handle is gone altogether) | |
| 5 | Validation of xpath | options order of implement and also performance cost!
| |
| 6 | can DMI plugin 'reject' a subscription create create (for a given cm-handel-xpath combination) | As NCMP might not validate as per issue#5 the DMI=plugin or component further down might have to reject an invalid xpath... | |
| 7 | implementation question: should 'rejected' DMI-subscriptions be stored | I would think not |
Solution Proposals
Merge → Split
- NCMP treat treats a Client Subscription as one or more (small) DMI Subscriptions, each of which wil have there own state.
Each DMI Subscription is related to 1 or more client subscriptionsubscriptions.
If there is no more related client subscription the DMI Subscription can be deleted (once accepted by DMI Plugin)!
...
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Create Combinations
| Existing Subscription A | Client Create Subscription B Request | DMI Create Request | Data Model | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c1 ] | None |
| |||||||||||||||||||||||||||||||
| 2 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c2, /p/c3 ] | CH-1, [ /p/c3 ] |
| |||||||||||||||||||||||||||||||
| 3 | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-2, [ /p/c1] CH-3, [ /p/c1] | CH-3, [ /p/c1] |
| |||||||||||||||||||||||||||||||
| 4 | CH-1, [ /p/c1] | CH-1, [ /p/c1/gc1 ] | CH-1, [ /p/c1/gc1 ] (see issue #1) |
| |||||||||||||||||||||||||||||||
...
| NCMP Existing A | NCMP Existing B | Client Delete A Request | DMI Delete Request | |
|---|---|---|---|---|
| 1 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c1 ] | CH-1, [ /p/c1, p/c2 ] | CH-1, [ p/c2 ] |
| 2 | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-2, [ /p/c1] CH-3, [ /p/c1] | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-1, [ /p/c1] |
| 3 | CH-1, [ /p/c1] | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-1, [ /p/c1] | None |
Error-upon error Combinations
| Previous Interaction | Current Interaction | Expectation | Notes | |
|---|---|---|---|---|
| 1 | create rejected for non-existing cm-handle | create for same non-existing cm-handle | listed in 'rejected' immediately | |
| 2 | create pending | create for same cm-handle/xpath | TBD send again or just remain pending?! | |
| 3 | create pending | delete for same cm-handle/xpath | ||
| 4 | delete pending | delete for same cm-handle/xpath | ||
| 5 | delete pending | create for same cm-handle/xpath |
Proposed JIRAs
| Priority | Component | Description | JIRA | Estimates |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 | ||||
| 6 | ||||
| 7 | ||||
| 8 |
...