Subject: [Netconf] Subscriptions to non-existent data

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Mon, 1 May 2017 14:44:41 +0000

All,

In looking at the subscribed notifications draft (https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-02), I'd like to suggest that we alter the language to permit the existence of subscriptions to data that doesn't exist (but could). Obviously, subscriptions to invalidly specified data should fail, but as an example, a subscription to the operational state of an interface that hasn't yet been created should be permitted.

The pros are:
* easier to implement: no check of presence of data
* faster setup time: again, no check for presence of data
* potential to subscribe to entire lifetime of data
* consistent behaviour for configured and dynamic subscriptions

The cons:
* use resources for things that may never exist, including connections to receivers

Lifetime Monitoring:

This approach allows the subscription to the entire life of objects. While this in some cases be handled by subscribing to the parent object, it doesn't work if a top-level object itself is the item of interest, in particular if it's a presence container. In this case, it may be important to know exactly when the presence container appears, disappears and re-appears.

Other notes:

Configured subscriptions for things that don't exist effectively require the publisher to place a subscription on the nearest existing parent object, and maintain that internal subscription until the subscribed to item exists, and then at that time, make the subscription active. This is complicated by the possibility that the path to the item of interest can lengthen or shorten before the item comes into existence. The result is that there is less net resource savings in the configured subscription case, and implementation is more complex, because the type/use of the subscription has to change when the data appears and again when the data disappears.

Instead, if the subscription is considered valid, connections to receivers can be setup and the true state of the subscribed to data can be sent to the receivers. There is no need for internal subscriptions that affect the state of configured subscriptions. It also makes the implementation behaviour between dynamic and static subscriptions more consistent: there is no internal change of behaviour when the subscribed-to data doesn't exist.

Expected behaviour:

For on-change triggered subscriptions to non-existent data with no-sync-on-start disabled, the initial sync would be an empty update notification.

For periodic triggered subscriptions to non-existent data, the expectation is that empty update notifications are sent at the period requested.

Note that when the subscribed to data appears, an access permissions check must be done. If the subscriber/receiver has no permission to access the data, the behaviour toward that subscriber/receiver continues as though the data does not exist.

Similarly, when the data ceases to exist, or access permission change occurs that prevents the receiver from access the data, the update notifications must convey the idea that the data no longer exists. This means for an on-change triggered subscription, a delete operation is sent. Note that allowing subscriptions to non-existent data doesn't change the latter behaviour. All that would change is that the subscription is not deleted after the delete update notification is sent.

Thanks,

Tim Jenkins

-- 
Cisco Systems Canada Co.
2000 Innovation Drive
Kanata, ON, Canada, K2K 3E8
Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>

---

From: Phil Shafer <[email-masked]>
Date: Mon, 1 May 2017 14:38:58 -0400

+1

---

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Mon, 1 May 2017 18:59:08 +0000

All,

A clarification: this is really directed more at YANG-Push (https://tools.ietf.org/html/draft-ietf-netconf-yang-push-05) than it is at subscribed notifications.

Sorry for the confusion, if any.

Tim

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Monday, May 1, 2017 at 10:44 AM
To: "[email-masked]" <[email-masked]>
Subject: Subscriptions to non-existent data

All,

The pros are:

The cons:

Lifetime Monitoring:

Other notes:

Expected behaviour:

Thanks,

Tim Jenkins

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 1 May 2017 20:07:56 +0000

This seems a reasonable change to yang-push.   It does make implementation simpler as they don't have to worry about some complex enforcement cases.  For example, you don't have to worry about recreating subscriptions when data disappears then reappears.  In fact it is actually is more robust as you can put subscriptions in anticipation of the creation of certain objects.

The downsides are you lose some protections for left over subscriptions hanging around in memory.  But there are other ways of addressing that which will be needed in the larger solution space anyway.

Eric

> From: Phil Shafer, Monday, May 1, 2017 2:39 PM
> +1
> 
> 
> >In looking at the subscribed notifications draft
> (https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-02), I'd
> like to suggest that we alter the language to permit the existence of
> subscriptions to data that doesn't exist (but could). Obviously, subscriptions to
> invalidly specified data should fail, but as an example, a subscription to the
> operational state of an interface that hasn't yet been created should be
> permitted.
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 2 May 2017 18:48:47 +0000

What language would you like to see altered?  The current draft already supports subscriptions to data that doesn't exist yet.  For example, new list elements can be created when a subscription is in progress and an on-change subscription will call this out (new data nodes created, that weren't there before) specifically.   

The one thing that used to be called out as required was the presence of the target data node that serves as the root.   However, this has all moved into the filter definition, leaving anyone free to create a filter that may not match anything already.  

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Monday, May 01, 2017 1:08 PM
To: Phil Shafer <[email-masked]>; Tim Jenkins (timjenki) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Subscriptions to non-existent data

Eric

> (https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notificatio
> ns-02), I'd like to suggest that we alter the language to permit the 
> existence of subscriptions to data that doesn't exist (but could). 
> Obviously, subscriptions to invalidly specified data should fail, but 
> as an example, a subscription to the operational state of an interface 
> that hasn't yet been created should be permitted.
>

---

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Tue, 2 May 2017 19:17:37 +0000

Alex,

It appears to be less clear in the latest draft, but the point is that it's not explicit either way. Some have interpreted this (section 3.7):

   A datastore subscription can be rejected for multiple reasons.  This

   includes the lack of read authorization on a requested data node, ...

as meaning that the data has to exist, perhaps in order to know the read permissions. Or perhaps there was a desire to reduce resource usage.

Regardless, what I'd like to see is explicit statements of the behaviour and descriptions of the update notification contents under those conditions, much like what I proposed below.

Tim

From: Alexander Clemm <[email-masked]>
Date: Tuesday, May 2, 2017 at 2:48 PM
To: "Eric Voit (evoit)" <[email-masked]>, Phil Shafer <[email-masked]>, "Tim Jenkins (timjenki)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Netconf] Subscriptions to non-existent data

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Monday, May 01, 2017 1:08 PM
To: Phil Shafer <[email-masked]<mailto:[email-masked]>>; Tim Jenkins (timjenki) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] Subscriptions to non-existent data

Eric

[email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 3 May 2017 00:08:16 +0000

Hi Tim,

Okay, definitely the behavior is something we should clarify (as well as how we would go about “garbage collecting” dysfunct subscriptions, as Eric alludes to)

Thanks
--- Alex

From: Tim Jenkins (timjenki) [mailto:[email-masked]]
Sent: Tuesday, May 02, 2017 12:18 PM
To: Alexander Clemm <[email-masked]>; Eric Voit (evoit) <[email-masked]>; Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Subscriptions to non-existent data

Alex,

Tim

From: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 2, 2017 at 2:48 PM
To: "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>, Phil Shafer <[email-masked]<mailto:[email-masked]>>, "Tim Jenkins (timjenki)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netconf] Subscriptions to non-existent data

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Monday, May 01, 2017 1:08 PM
To: Phil Shafer <[email-masked]<mailto:[email-masked]>>; Tim Jenkins (timjenki) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] Subscriptions to non-existent data

Eric