Re: [Netconf] configured subscriptions over netconf and restconf

[Kent Watsen <[e-mail]>]

I see value in having dynamic subscriptions over NC and RC (convenience). 

The value in having configured subscriptions over NC and RC is less, especially given the ability for a client to do a dynamic subscription over a standard NC/RC call-home connection, but I don’t particularly oppose it either (convenience again). 

That said, using NC/RC for a configured subscription is not my first choice. 

When performance is not a concern, then the simplicity of using XML/JSON over HTTP/2 is compelling. 

When performance matters, which I view being the situation for all but the simplest cases, a binary protocol over UDP with optional encryption sent from the data plane is ideal.  [disclosure: I designed an encrypted binary logging protocol over UDP about 15 years ago]

I believe the draft correctly explains the need for a client of a configured subscription to issue dynamic subscriptions.  Ideally, these dynamic subscriptions can occur over the same transport, as the server-initiated connection may have been needed to get thru a NAT/FW.  Such should be considered for transports used for configured subscriptions. 

To answer your question, I am neither currently implementing, nor personally interested in implementing, configured subscriptions over NC/RC.  Of course, if a customer asked for it, I wouldn’t hesitate to support it, amongst other transport options available for selection.

Kent // contributor 


> On Jul 20, 2018, at 6:02 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> Hi,
> 
> thinking more about this, I wonder who is interested (in the sense I
> am implementing this) in configured subscriptions over NETCONF and
> RESTCONF (SSE - not some new HTTP/2 transport, which is not RESTCONF).
> 
> It could be that NC and RC clients are just fine with doing dynamic
> subscriptions (since they can) and configured subscriptions
> essentially exist to use notification streaming protocols that
> themself have no way to dynamically subscribe. If this would be true,
> then defining a transport for configured subscriptions over plain NC
> and RC seems like a waste of effort. Then I would rather be specific
> that configured subscriptions are for non NC/RC transports and remove
> the text how to make configured subscriptions work with NC/RC.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=t68D61ThFCbRZxMn-imJ13HOyBGipKykSnO5bUstA4Y&s=tHVmdmFh2_ykikTj-LNhhO9DzHZfbMxDUdw01-8FL28&e=>
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=t68D61ThFCbRZxMn-imJ13HOyBGipKykSnO5bUstA4Y&s=rL159FYIGJ3-E2zvw8KDBqpfhENBq0lU_uRIMy7opYk&e=