Subject: [Netconf] configured subscriptions over netconf and restconf

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Jul 2018 12:02:29 +0200

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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Jul 2018 14:39:29 +0200

On Fri, Jul 20, 2018 at 12:21:47PM +0000, Kent Watsen wrote:
> 
> I believe the draft correctly explains the need for a client of a configured subscription to issue dynamic subscriptions.
>

Not sure what you mean with this. Which section do you refer to?

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Jul 2018 13:02:55 +0000

> Not sure what you mean with this. Which section do you refer to?

I’m not looking at it right now, but I know that there’s a statement in the Security Considerations section. 

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Jul 2018 15:17:14 +0200

> I’m not looking at it right now, but I know that there’s a statement in the Security Considerations section. 

draft-ietf-netconf-netconf-event-notifications-10.txt:

10.  Security Considerations

   Notification messages (including state change notifications) are
   never sent before the NETCONF capabilities exchange has completed.

   If a malicious or buggy NETCONF subscriber sends a number of
   establish-subscription requests, then these subscriptions accumulate
   and may use up system resources.  In such a situation, subscriptions
   MAY be terminated by terminating the underlying NETCONF session.  The
   publisher MAY also suspend or terminate a subset of the active
   subscriptions on that NETCONF session.

   This draft has a YANG module which consists of a single identity.  As
   a result additional security concerns beyond those of the imported
   modules are not introduced.

The first paragraph is interesting but it is not clear why it is in
the security considerations. The second paragraph talks about a thread
but leaves out what happens to configured subscriptions created by a
malicious client. The last one says that the identity defined in the
YANG module has no security issues. The completeness of the security
considerations can perhaps be debated but anyway I see nothing
concerning "the need for a client of a configured subscription to
issue dynamic subscriptions".

Let me try draft-ietf-netconf-subscribed-notifications-14.txt. I find:

   With configured subscriptions, one or more publishers could be used
   to overwhelm a receiver.  Notification messages SHOULD NOT be sent to
   any receiver which does not support this specification.  Receivers
   that do not want notification messages need only terminate or refuse
   any transport sessions from the publisher.

So a notification receiver must implement
draft-ietf-netconf-subscribed-notifications-14.txt? How does the
server determine that the client did implement
draft-ietf-netconf-subscribed-notifications-14.txt?

   When a receiver of a configured subscription gets a new
   "subscription-started" message for a known subscription where it is
   already consuming events, the receiver SHOULD retrieve any event
   records generated since the last event record was received.  This can
   be accomplish by establishing a separate dynamic replay subscription
   with the same filtering criteria with the publisher", assuming the
   publisher supports the "replay" feature.

This is perhaps what you mean. But I wonder how this works for
transports that can't establish dynamic subscriptions. Note that this
is a SHOULD. Hence any transport SHOULD be able to create dynamic
subscriptions.

The more I look at these documents, the more questions pop up...

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Jul 2018 12:21:47 +0000

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 <[email-masked]> wrote:
> 
> Hi,
> 
> Fax:   +49 421 200 3103         <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
> [email-masked]
> 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=

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 20 Jul 2018 19:05:50 +0000

Some thoughts on the business need:

- Configured subscriptions over RESTCONF is not something of interest to me.

- I have not seen many requests for configured subscriptions over NETCONF.   Like Kent, we are prepared to implement these if given a business case.

- What we do have in production is multiple variants of configured subscriptions over proprietary transport. 

- On past threads, Henk has stated he needs configured subscriptions standardized now for non-NC/RC transports.  (So progressing configured in SN makes sense.)

So I completely agree with your premise below.  In fact, this was option A2 during Monday's WG meeting.  To support this, we have already scoped out the document changes which would be needed to correspondingly reduce the scope of NETCONF-Notif to just dynamic subscriptions.

Eric

> -----Original Message-----
> From: Netconf <[email-masked]> On Behalf Of Juergen
> Schoenwaelder
> Sent: Friday, July 20, 2018 6:02 AM
> To: [email-masked]
> Subject: [Netconf] configured subscriptions over netconf and restconf
> 
> Hi,
> 
> thinking more about this, I wonder who is interested (in the sense I am
> implementing this) in configured subscriptions over NETCONF and
> 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
> 
> --
> https://www.ietf.org/mailman/listinfo/netconf