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

[Martin Bjorklund <[e-mail]>]

Hi,

Alexander Clemm <[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.

Hmm, which filter are you talking about?  The only XPath filter I find
in the current set of documents is the
"ietf-subscribed-notifications:xpath" filter type (which btw is sorely
underspecified).  Section 2.2 of
draft-ietf-netconf-subscribed-notifications-02 says:

   Events which evaluate to "true" as a
   result of the evaluation by the filter must traverse the filter in
   their entirety.

It's not clear what this means, but my guess is that this is supposed
to work like the old RFC 5277 filters, where the filter expression is
evaluated on the notification contents, and if the expression returns
"true" (for XPath filters this means converting the results to a
boolean), then the notification is sent, otherwise not.

But it seems you are referring to some other filter which would be
used to select a node set for which changes are reported?

I would like to understand which filter mechanism you mean before
having an opinion in this matter.


/martin




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