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

[Martin Bjorklund <[e-mail]>]

"Eric Voit (evoit)" <[e-mail]> wrote:
> 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.

This has been pointed out before - the restconf-notif draft should
define *RESTCONF* mechanisms for subscribed notifications.

If you want to define a new "notif-only" protocol that uses HTTP/2,
that should be done in a separate document.

Also, with the addition of a "activate-configured-subecription", we
can use existing RESTCONF mechanisms to support configured
subscriptions; it more or less falls out for free, as I explained.

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

Maybe another reason to do this in a separate document.

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

The idea is that the "reciever RPC" is NOT mandatory; if a transport
needs such an RPC in order to start the notif flow, the transport
document will specifiy that the "activate-configured-subscription" rpc
is used for that transport.

If a new "notif-only" protocol is defined that doesn't utilize this
rpc, the transport spec for that protocol will not use it.

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

I was hoping we would be able to get configured subscriptions to work,
for NETCONF and RESTCONF, sooner rather than later.


/martin



> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
>