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

["Eric Voit (evoit)" <[e-mail]>]

> From: Martin Bjorklund, May 18, 2017 2:50 AM
> 
> 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.

This is the case for events.  For these, the filter should result in a yes/no for any event in a stream.
 
> But it seems you are referring to some other filter which would be used to
> select a node set for which changes are reported?

For datastores, I suspect the RFC6241 selection filter should be the dominant one.   But it is conceivable that an XPATH selection filter (i.e., not a boolean result) could be provided. 

Eric

> 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
> >
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf