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

Hi Martin,

> From: Martin Bjorklund, September 12, 2018 8:01 AM
> 
> 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".

Thanks.  I have included this as a note to the RFC Editor within NETCONF-Notif.

> 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.

Yes, protocol specific is what has been assumed for the current draft set.  

> 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. 

Perhaps something will be needed for NETCONF.  But for configured RESTCONF subscriptions, RESTCONF-Notif has been assuming that RESTCONF not be used.  Instead raw HTTP2 with the Publisher being the HTTP client and the receiver the HTTP server seems cleaner.  And the HTTP server need not respond with an 'ok' to a "subscription-started" unless it is ready to accept event records.  So I think there are open questions on the best way to do HTTP configured transport.

> 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.

Perhaps this could be useful.  But it would be great wherever possible if we can avoid receiver RPCs as a mandatory element of the establishment flow with a configured publisher.  So I believe we should investigate further on this for NETCONF configured in the coming months.   If it does turn out useful, I would like to see more than NETCONF potentially make use of the RPC before generalizing to the SN level.

> 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.

Defining something local to a protocol might be ok until we get some clarity on the generality of this issue.

Eric

> 
> /martin
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf