...
| 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! Consider:
| |||
| 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 | do NOT delete dmi-subscription entry until owning subscription is deleted Note. LCM is already broadcast (today) |
| ||
| 5 | Validation of xpath | options order of implement and also performance cost!
| |||
| 6 | can DMI plugin 'reject' a subscription create (for a given cm-handle-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... | yes currently DMI can use response to say which cm handles are not accepted i.e. rejected' (but not 'pending') | ||
| 7 | implementation question: should 'rejected' DMI-subscriptions be stored | not needed as whole subscription should be rejected | |||
| 8 | Dimensioning of DB depends on #cm handles, #subscriptions and #xpaths per subscription, this could be too big for fast processing of updates! | Need to agree maximum and possibly realistic average/total number of entries based on the characteristics above | wil will affect the way the data needs to be modelled exactly | ongoing but not completed!. | - kieran mccarthy- Dimensioning has been agreed. |
| 9 | Maximum (error) message size | theoretically all cm handles and all xpaths combinations could be rejected or pending leading to a very large error message! | |||
| 10 | can each CM-Handle have different set of xpath(s) per subscription | the current 'basic' solution only supports a common set of datastore/xpaths (filter) | |||
| 11 | can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies) |
| Although this wiki-page will not be updated where cmHandle+xpath is mentioned as unique entry etc. this should now include a third field: datastore as well. | ||
| 12 | Will migration from 'basic' be supported | Preferred to ask customers to create new subscriptions | |||
| 13 | list v list instances filtering | /p/c1 | |||
| 14 | confirm subscription id (currently subscription name + client id) | ||||
| 15 | what subscription details should be send when there is a change (in the union) |
| |||
| 16 | one DMI rejects whole (see decision #6) subscription (affected cmhandles) but other DMI accepts the same subscription, is this possible how to handle | ||||
| 17 | What all datastores are supported ? | ncmp-datastore:passthrough-running or ncmp-datastore:passthrough-operational ?? or both? | - kieran mccarthy Both will be supported |
Solution Proposal
State handling for initial (basic)subscription create/delete use cases (not using concept of 'merging')
...