Page History

...

#	Interface	Requirement	Additional Information
1	CPS-E-08.e	NCMP is to merge CM Notification Subscriptions Create request for the same CM Handle & XPath(s)	Prevent unnecessary subscription updates to nodes already involved in a subscription to the same path For possible combinations, see table below
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 Scenario	Expected behavior	Sign-off
1
2

...

Issues & Decisions

ire

#	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 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)

...