Jira | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Table of Contents |
---|
Requirements
Functional
...
Requirement
...
- Prevent unnecessary subscription updates to nodes already involved in a subscription to the same path
- For possible combinations, see table below
...
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)
...
Error Handling
...
Characteristics
...
Out-of-scope
- CM Notification Forwarding Check: When forwarding CM Notification NCMP will not check the content to see if the is a valid active subscription. It is assumed that the DMI Plugin as acted on the 'delete subscription' request (that request is NCMPs responsibility). And of course there wil be timing issues it also possible a CM Notification was send just after the subscription-delete was send (from client) but before the whole change had acted upon that.
- Retry: NCMP wil only report when actions are pending or rejected. NCMP will not implement a retry mechanism
- Wildcards: Wildcards or similar functionality where one string represent 0 or more xpaths is not covered as part of this requirement but it should be kept in mind as a future possibility
- Dynamic Topic: Topic for CM Data Notifications back to client will be hardcode for now
Assumptions
...
Issues & Decisions
...
Solution Proposals
Merge → Split
- NCMP treat 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 subscription.
If there is no more related client subscription the DMI Subscription can be deleted (once accepted by DMI Plugin)!
...
Create Combinations
...
Delete Combinations
...
Proposed JIRAs
...
This study is now included in CM Data Notification Subscription LCM (incl. merge)