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

[Andy Bierman <[e-mail]>]

Hi,

I wonder why we really need the client to choose to subscribe to
"micro-events".
It makes sense to me for subscriptions to instance data using keys and
static leafs like if:type.
Subscribing to "foo=5" does not seem that useful for replicating state or
anything else.
YANG Push should not include RMON Alarms & Events type of functionality.

The trick to good standards writing is to support the use-cases in a way
that
does not introduce massive implementation complexity for functionality
outside those use-cases.

So I would pick (3) and add a warning about avoiding filters for volatile
data nodes
such as counters.


Andy


On Wed, May 17, 2017 at 2:29 PM, 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.  (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
>
>