[Netconf] activate-configured-subecription - WGLC subscribed-notifications-16

[Martin Bjorklund <[e-mail]>]

Hi,

I forgot one thing in my review, that has been discussed (slightly
off-topic) in the thread "netconf call home connection type".

The SN draft (implicitly) assumes that for dynamic subscriptions,
after a successful "establish-subscription" operation, notification
messages can start to flow to the client.

The exact mechanism for this is transport-protocol-dependent.

For NETCONF, the netconf-notif draft will need to update RFC 6241,
since 6241 refers to 5277 which says that a <notification> message can
only be sent after a successful "create-subscription".  netconf-notif
updates this to allow <notification> messages to also be sent after a
succsessful "establish-subscription".

For RESTCONF, the restconf-notif draft defines a new mechanism for how
notifications are delivered; instead of locating the SSE resource url
from the "streams" in "ietf-restconf-monitoring", this draft now
augments a location leaf to the output of "establish-subscription".
(It probably doesn't have to update 8040, but *maybe* the mechanism in
8040 ought to be deprecated)


For configured subscriptions however, the SN draft doesn't specify how
the flow of notifications should start.  One view is that this is
transport-protocol-specific.  However, I think that for all RPC-based
transport-protocols (currently NETCONF and RESTCONF) it makes sense to
have a common way to get the notifications to be sent.  Hence I
suggest that this draft adds a new rpc operation
"activate-configured-subscription" (better name anyone?).  This rpc
would be invoked by the client after a call home to start the flow of
configured subscriptions.  If there are no such subscriptions or the
session is not a call home session and error would be returned.

We might define non-RPC-based transport protocols for configured
subscriptions in the future.  Such a protocol can obviously not use
this rpc, but OTOH it can't use establish-subscription either.  I
think this is ok.

With such an RPC, netconf-notif would udate 6241 to say that
<notification> messages can be sent after a succsessful
"establish-subscription" or "activate-configured-subscription" rpc.

And with such an RPC, restconf-notif can support configured
subscriptions over proper RESTCONF; it would augment a "location" leaf
to the output of activate-configured-subscription, which would contain
the URL to the event flow, so that it works just like dynamic
subscriptions.


If we don't add this RPC to the SN draft, each protocol draft will
have to define its own version of this operation.



/martin