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
Hello Allan, In the end I realized that the notificationId only need be unique in the context of a conectionId, since we are retrieving using the connectionId for additional context. The DataPlaneStateChange notification was left out of the queryNotification since the current state can be determined by querying the state machine. At least, this was my justification for leaving them out. Do you see a use case that would require these notifications to be included? It definitely would make the solution complete around notifications. John On 2013-06-20, at 11:15 AM, Alan van Dam <avandam@zilverline.com> wrote:
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 _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi John, The use case for querying the data plane state change notifications would be to retrieve history of release/provision. Not sure if that is really useful. But for us the biggest argument to include the data plane notifications in the queryNotifications response is the 'principle of least surprise'. Because DataPlaneStateChange is a notification and has a notificationId you would expect that the operation queryNotifications returns all notifications including data plane state changes. The other 'solution' would be to don't let DataPlaneStateChange extend NotificationBaseType. But I think it is correct that DataPlaneStateChange is a notification to the requester. Cheers, Alan On 20 jun. 2013, at 17:26, John MacAuley <john.macauley@surfnet.nl> wrote:
Hello Allan,
In the end I realized that the notificationId only need be unique in the context of a conectionId, since we are retrieving using the connectionId for additional context.
The DataPlaneStateChange notification was left out of the queryNotification since the current state can be determined by querying the state machine. At least, this was my justification for leaving them out. Do you see a use case that would require these notifications to be included? It definitely would make the solution complete around notifications.
John
On 2013-06-20, at 11:15 AM, Alan van Dam <avandam@zilverline.com> wrote:
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 _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (2)
-
Alan van Dam -
John MacAuley