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

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[e-mail]> wrote:
> Hi,
> 
> On 24/05/2017 23:25, Alexander Clemm wrote:
> > Let me briefly summarize where I think we are. The thread has clearly
> > moved on from the initial issue of how to distinguish between causes
> > for updates to no longer include a given data node (because it was
> > deleted, or because it changed its value to no longer match a filter)
> > to other issues.
> >
> > For those other issues, I think there are in fact two separate items
> > that we are trying to discuss at the same time, which are really
> > orthogonal to one another:
> >
> > - The first item concerns the concept of a "filter" vs a "selector".  A
> > - filter is what gets specified for any subscription to notifications,
> > - which defines which notifications a subscriber wants to receive.  The
> > - filter is applied to the notification as a whole, i.e. either the
> > - notification is delivered or it is not.  It does not apply to subsets
> > - of contents within the notification.  A selector, on the other hand,
> > - is used to specify updates of which data nodes to include in a
> > - YANG-push subscription.  The same update notification could include
> > - updates of several data nodes, hence a filter applied to the
> > - notification as a whole would be inappropriate here - the semantics is
> > - slightly different: as a subscriber, "of which data nodes would you
> > - like to receive updates", not "which notifications would you like to
> > - receive".
> If you look at this problem in a slightly different way, then I'm not
> sure that "selectors" are necessarily different from "filters".
> 
> One could see all subscribers of periodic and on-change YANG Push
> subscriptions to really be recipients of the same single conceptual
> stream of data node change (and periodic) updates from a
> datastore. This conceptual stream of changes can be regarded as an
> unbounded sequence of notifications, where each notification contains
> a change for one or more data nodes.  Under this description, it seems
> that a YANG Push "selector" then acts like a Notification "filter" in
> that it chooses which of those messages in that conceptual stream get
> sent on to each subscriber.

This has been discussed before.  I think it is a convoluted hack.  The
notifications would have to conceptually contain the entire datastore
(entire opertational state for example), and then you'd have to
handwave a bit to produce a pruned notification with just the nodes
the subscriber is interested in.   What's the point anyway when
there's already a clean, simple solution available?



/martin


> The only difference I see between "selectors" and "filters" is that
> the YANG push messages acted on by a selector COULD be pruned to only
> include the nodes of interest.  But perhaps this distinction is a
> actually a property of the type of notification that is being
> generated.  I.e. whether a notification can be pruned by a
> "filter/selector", or whether it is a binary decision to send or drop
> the notification message (like RFC 5277).
> 
> For notifications that could be pruned, then I think that the choice
> as to whether to prune the notification data should be an
> implementation choice, and that it should be acceptable to also send
> messages that include extra nodes that are not of interest, and
> perhaps in the extreme case to send some notifications that don't
> actually contain any nodes of interest at all!
> 
> Rob
>