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

[Andy Bierman <[e-mail]>]

On Fri, May 19, 2017 at 2:30 PM, Alexander Clemm <[e-mail]
> wrote:

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


I guess I like option #4 (allow data filters on static data, say SHOULD NOT
use on dynamic data)
The solution seems too complicated if there is a need for "I am still here,
but I am not being reported" .
Especially since that means "still here in your custom view of things", not
"still here in the device".


--- Alex
>


Andy


>
>
> *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]> wrote:
>
> Hi Andy,
>
> Below
>
> --- Alex
>
>
>
> *From:* Andy Bierman [mailto:[e-mail]]
> *Sent:* Thursday, May 18, 2017 6:34 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?
>
>
>
> ……………………
>
> <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
>
>
>
>
>
>
>