[Nsi-wg] Proposal: Subscribing of events in NSI

[Henrik Thostrup Jensen]

Hi

On Thu, 18 Apr 2013, John MacAuley wrote:

> Having notification subscriptions in a product I am currently working on 
> makes me oversensitive to the issues that can crop up.  Here is some 
> food for thought…

It is always easy to add stuff :-).

> Should we support the ability to query subscriptions?  Would it be 
> useful for an RA to query the PA for all valid subscriptions so it can 
> audit after error and restart scenarios?

I'd say no. An RA can just resubscribe instead of trying to probe the 
state. This is a pattern which I see a bit too often IMHO: Trying to 
figure out the current state and the reacting on it. Just do the damn 
thing. Detecting duplicate strings and saying OK is not complicated.

> Would providing a filter on registration be useful?  For example, I only 
> want to be notified of dataPlaneStateChange events on a connectionId. 
> I am trying to think of an application that might find this useful, but 
> i think they would also want to know about errors, so maybe the filter 
> provides no value here.

The number of notifications is going to be relatively small, so I'd say 
the client can do the filtering.

> I assume a goal here is to not introduce the concept of a subscriptionId, so we will need to specify endpoint and connectionId in unsubscribe operations:
>
> subscribe(connectionId[], endpoint, *filter*);
> unsubscribe(connectionId[], endpoint);
> listByConnectionId(connectionId[]);
> listByEndpoint(endpoint);

I don't really think we need the latter two and the filter.

> Some things to thin about:
>
> - Are subscriptions persistent?

I'd say yes, otherwise they are not really useful.

> - Are subscriptions removed automatically when the schedule is terminated (or after a guard time to make sure dataPlaneStateChange events have purculated up the tree).

I'd just remove them along with all the connection data, when it is reaped 
some time after termination. It is an array of strings, nothing 
complicated to keep in a database.

> - Define the behaviour around re-registering a subscription that already 
> exists.  I may restart and want to make sure I am registered by sending 
> down the same registration again.

That is ok. The PA should just detect the duplicate and return an OK. 
Idempotent operations are a good thing.

> - Do subscriptions time out?  For example, if I have not been able to 
> deliver notifications to an endpoint for an hour can I automatically
> delete the subscription?

A subscription is a static thing (at least as a starting point :-)).

A notification message can timeout if it cannot be delivered. Retries and 
such are OK, but at some point the notification must be dropped. Most who 
have worked with subscriptions outside a lab setup have realized that some 
notifications will be lost. The solution is typically to fallback to 
polling (query) for certain situations.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet