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

[Andy Bierman <[e-mail]>]

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