HiHi, The last couple of days we implemented the two new notification query operations in our UPA, BandwidthOnDemand. Doing this we had a few questions: * Sending a DataPlaneStateChange to the requester requires a notificationId. (A DataPlaneStateChangeRequestType extends a NotificationBaseType which has a notificationId.) Which suggests it is a notification that can be queried. When doing a notificationQuery the response (queryNotificationConfirmed) only contains errorEvent, reserveTimeout and messageDeliveryTimeout notifications. We expected it to contain DataPlaneStateChanges as well, because it is a notification (it extends NotificationBaseType). I understand that the data plan state can be queried with a querySummary but the history of provision/release can not. I would suggest to let queryNotification also return the data plane state change notifications. * In the pdf attached to issue 92 solution 2b says that the notificationId should be unique per NSA. Currently we implemented the connectionId to be unique per connection. I think this makes it easier to follow the notifications because there should be almost no gaps between the notification ids. If the query contains the data plane state change notifications no gaps at all. Cheers, Alan van Dam Team member of SURFnet BandwidthOnDemand