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

[Andy Bierman <[e-mail]>]

On Thu, May 18, 2017 at 2:15 PM, Kent Watsen <[e-mail]> wrote:

> I'm unsure if this is a good example, but assuming you have data model
> snippet:
>
>
>
>   list foo {
>
>     key name;
>
>     leaf name { type string;}
>
>   }
>
>
>
> and the on-change subscription snippet:
>
>
>
>    /foo[name="x]
>
>
>
> and the following occurs in time:
>
>
>
>   T0: there are no 'foo' entries
>
>   T1: foo entry w/ name=="y" is created
>
>   T2: foo entry w/ name=="x" is created
>
>   T3: foo entry "x" is renamed to "z"
>
>   T4: foo entry "y" is renamed to "x"
>


Do you mean some proprietary non-standard rename operation?
Because NETCONF and RESTCONF have only delete(x) and create(y)


>   T5: foo entry "x" is deleted
>
>
>
> I'd expect:
>
>
>
>   T0: nothing
>
>   T1: nothing
>
>   T2: "x" created notification
>
>   T3: "x" modified-out notification
>
>   T4: "x" modified-in notification
>


T3 and T4 events are not possible in NETCONF or RESTCONF.
There is no way to rename a data node. These protocols will
produce delete(x) and a create(y) events


  T5: "x" deleted notification
>
>
>
> I think that this is your #2.
>
>
>
> Kent  // as a contributor
>
>
>
>
>


Andy


>
>
> On 5/17/17, 5:29 PM, "Netconf on behalf of Alexander Clemm" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>
>
> Hello all,
>
>
>
> In updating the YANG-Push document (draft-ietf-netconf-yang-push), we
> have come across one issue that we wanted to raise with the working group.
>
>
>
> As part of an on-change subscription, update records reflect the type of
> change (e.g. whether the value of an object has changed, or whether an
> object was created or deleted); a subscription allows also to specify
> whether interested only in specific types of changes (for example, only
> creates and deleted but no value changes).
>
>
>
> At the same time, a subscription filter specifies which objects to include
> as part of a subscription and which not.  (Really, it is not so much of a
> “filter” on a stream that is generated independently of the filter, than it
> is a policy of which objects to include as part of subscribed update
> records.)   However, a subscription filter (such as XPath) can be used to
> also specify a value filter, which will include or exclude objects based on
> their current value. This makes it possible to e.g. subscribe to an object
> “foo” but only if its value is 5.
>
>
>
> Now, this means that the same object could be included in one update, but
> excluded in another update, due to its value no longer meeting the filter
> criteria.  For example, if foo’s value changes from 5 to 3 in one cycle, a
> periodic subscription will no longer include foo in its next update.  The
> question now concerns how to properly handle this in the case of an
> on-change subscription.
>
>
>
> One possibility concerns reporting the fact that “foo” no longer meets the
> subscription criteria and is no longer included in the update record as a
> “delete” event.  If foo’s value again becomes “5” at a later point in time,
> that would be reported as a “create” event.  If foo’s value changes again
> from 5 at a later point in time and then changes back to 3  before the time
> of the update (perhaps because the value changed during the dampening
> interval), it would be reported as another “delete” event (without ever
> reporting a create event).  On the other hand, if foo’s value changed from
> 3 to 6 and back again, nothing would be reported because it did not meet
> the filter criteria at any point in time.
>
>
>
> From the perspective of the receiver this may make sense if it is synching
> its copy of the state.  However, from the perspective of the publisher, the
> object was never created or deleted – only its value changed, and the case
> when the object was truly created or deleted can no longer be distinguished
> from the case when its value changed.  A “create” simply means “an object
> now meets a filter criteria, that was not reported in the previous cycle”
> (which does not mean that the object was actually created – it may have
> been created, or it may have simply undergone a value change).
>
>
>
> An alternative (let’s call it alternative 2) is therefore to make a
> distinction between whether an object was created or deleted, or whether
> its value fell in or out of a filter range.  This appears semantically
> cleaner.  However, it will require modifying the encoding to allow for
> distinction between those cases (currently, just plain patch encoding is
> used).
>
>
>
> A third alternative is to let filters select only data nodes to subscribe
> to, and separate out the value filter (or disallow it as a feature
> altogether).  This alternative has the drawback of being less conceptually
> powerful, even if it may be easier to implement.
>
>
>
> Thoughts?  Any preferences between 1, 2, and 3?
>
> --- Alex
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>