Re: [Netconf] In an update, when is a delete a delete?

[Alexander Clemm <[e-mail]>]

Hi Andy,

I am not sure I understand your question below.  I am not referring to mix-and-match between subscription – not to bundling or anything like that.  Merely to an on-change subscription.

If we do send updates regarding changes, and a subscription allows to apply a “value filter”, there are cases when a change is caused by a node being deleted since the last update cycle, and there are cases when a change is caused by a node changing its value so it no longer matches the value of the filter (and create case accordingly).  This can clearly occur.  Given this, I think we are faced with the alternative of either being able to properly distinguish the two (option #2 in the earlier thread), or disallowing filters based on data node value (option #3).  I was under the impression you were arguing for #3 earlier?

--- Alex

From: Andy Bierman [mailto:[e-mail]]
Sent: Thursday, May 18, 2017 8:50 PM
To: Alexander Clemm <[e-mail]>
Cc: Kent Watsen <[e-mail]>; Eric Voit (evoit) <[e-mail]>; Netconf <[e-mail]>
Subject: Re: [Netconf] In an update, when is a delete a delete?

Hi Alex,

On Thu, May 18, 2017 at 6:51 PM, Alexander Clemm <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy,
Below
--- Alex

From: Andy Bierman [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, May 18, 2017 6:34 PM
To: Alexander Clemm <[e-mail]<mailto:[e-mail]>>
Cc: Kent Watsen <[e-mail]<mailto:[e-mail]>>; Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>>; Netconf <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Netconf] In an update, when is a delete a delete?

……………………
<snip>
I interpret the “modified-in” and “modified-out” suggested by Kent precisely as a distinction between those cases.  “Modified-out” simply means its value changed so it no longer matches the filter (but the object still exists).  Whether we call it modified-in/out or something else is another question.  Of course, the issue is that this means this is a new case that is not covered by the patch syntax, which would require an extension of the encoding.



What breaks if the client just sees data nodes appear or disappear from 1 patch to the next?
Why does the client need to know the data node still exists, but the foo==5 filter changed.
The client decided that only state for foo==5 needs to be watched, so from its POV
the extra metadata should not be needed.


<Alex>
For periodic, this is what happens.
In the case of on-change, we would indicate changes.  If a data node is not included in an update, how would we be able to distinguish between the case of (not included because no change) and (not included because no longer meets the filter)?  We do need to indicate to the subscriber that there has been a change in that the data node no longer meets the criteria.  Presumably we want to distinguish this from the case that the data node ceased to exist.  (Not distinguishing those cases would put us back to alternative #1, which I think the consensus is that we don’t want that)
</ALEX>


Regarding not included because of no-change:

How can happen/?
Not if the client is requesting non-overlapping subtrees /foo and /bar.
These are safe to mix in 1 subscription. The client should not assume
that an update for /foo means /bar was deleted.

Are you referring to overlapping subtrees in 1 subscription?
How would this be configured? Seems complicated to manage.
The semantics of "on-change" should be easy to manage on both client and server.


Andy