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

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

Hi Martin,

Good discussion.  Some thoughts in-line...

> From: Martin Bjorklund, May 26, 2017 11:30 AM
> 
> Hi,
> 
> See below for a correction.
> 
> Martin Bjorklund <[e-mail]> wrote:
> > Hi,
> >
> > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > Hi Martin,
> > >
> > > There are two differences in what we are describing:
> > > (#1) Do we have a parent identity which spans both the test filter
> > > types and the selection filter types
> > > (#2) Should we expose additional filter parameters within the YANG
> > > model
> > >
> > > For (#1), I see no harm in providing a parent identity.
> >
> > I do, since there is no benefit in a common parent identity.  It just
> > adds complexity to what's really a simple model.

There are three options for traversing the filter criteria subtyping:
(a) filter sub-typing defined by a multi-tier identity hierarchy
(b) explicit subtyping for selection vs. test, with independent identity sets
(c) explicit subtyping for all current and future types of filters

If we ever use (a) in any form, there is value in a parent identity.  As the current working draft is based (b), I will pull it out.  We can always re-add in parallel with (b) if someone expresses a business need.

> > > Perhaps your
> > > concern is documentation compatibility with what was previously
> > > driven by 5277?
> >
> > No.
> >
> > > If that is the case, we could rename the top level filter to
> > > "evaluation-criteria".  This would free up "test-filter" to be
> > > renamed to "filter".  If this is ok, below is what is in the might
> > > be included in subscribed-notifications.  I believe matches to what
> > > you are suggesting, with the exception of the top level
> > > evaluation-criteria identity.
> > >
> > >   identity evaluation-criteria {
> > >     description
> > >       "Base identity for representing types of filtering or selection
> > >       syntaxes which may be applied against some target.";
> > >   }
> > >   identity filter {
> > >     base evaluation-criteria;
> > >     description
> > >       "Evaluation criteria used as a pass/fail test against events.  A
> > >       boolean true, or a non-null result of a node
> > >        selection will allow events to traverse the filter.";
> > >   }
> > >   identity subtree-filter {
> > >     base filter;
> > >     description
> > >       "A RFC-6241 based filter which attempts to select nodes within an
> > >       event.  A successful
> > >        selection of any nodes results in a positive test result.";
> > >     reference "RFC-6241, #5.1";
> > >   }
> > >   identity xpath-filter {
> > >     base filter;
> > >     description
> > >       "A filter applied to an event which follows the syntax specified in
> > >       yang:xpath1.0. Success
> > >        is indicated by either a positive boolean result, or a non-null node
> > >        selection.";
> > >     reference "XPATH: http://www.w3.org/TR/1999/REC-xpath-19991116";
> > >   }
> > >
> > >
> > > For (#2), within the YANG model we expose a target for the
> > > evaluation-criteria (i.e., a stream or datastore) and the anydata.
> > > I don't think we should try for more.  The subscription
> > > specifications are complex enough already.
> > >
> > > If we try to break out additional parameters from the opaque anydata
> > > (either selector or filter), there is going to be a desire to break
> > > out even more parameters.  And then there will be attempts to codify
> > > valid interplays with these parameters.
> >
> > I don't understand what this means.  Maybe you can provide an example
> > by using my proposal below?

Looking at your regexp example, I now see that by 'parameters', you also meant that you wanted a different yang object type for each type of supported filter.  I.e., you want (c).  My earlier interpretation was that you wanted (b) with additional parameters to break down the contents and interworkings of a common anydata event filter object.

The explicit subtyping with different object types that you have below close to what we had up through yang-push draft -v04 (minus your addition of the case regexp & dialect parameter).   Draft -v05 went the other way to (a) by minimizing the number and potential growth of filter object types via the addition of the filter-type.  Working draft -v06 is of (b), and is attempting to balance these needs.  The cost of both (a) and (b) is that we have a new object type, and the application must validate the filter-type syntax -- foregoing datatype enforcement by the model.  But as the application will need to do its own syntax checks for the enforcement for platform specific filtering capabilities anyway, this doesn't seem to be a bad tradeoff.

BTW: I also would have also leaned towards explicit subtyping of option (c) if it were definitively possible to know whether a platform could support a specific filter back at the subscriber.  But all filters will still need publisher validation, so yang data-type enforcement provides only minimal protections.   

So with (b) vs (c), it feels like we are coming a model style preference.  I have a preference for (b): the one with fewer object types, and the one where it is the identities which might grow over time.  If we remain with (b), the interface specification should be less verbose.

> > > There are many lifetimes of
> > > complexity here.  Your example of regexp is an excellent one, look at:
> > > https://en.wikipedia.org/wiki/Comparison_of_regular_expression_engin
> > > es it is hard for even a wiki page to maintain links to the
> > > variations.
> >
> > This is completely missing my point, which has to do with how filter
> > parameters are specified for new filters; not that there are many
> > regexp dialects.
> >
> > > If someone has a proposal for how to parameterize these filtering
> > > criteria simply, I would love to listen.  Note: Such a proposal may
> > > not disrupt other vendor syntaxes which can be transparently
> > > supported via the anyxml.  Absent such a proposal, we should leave
> > > the specifics up to implementations for now.
> >
> > [...]
> >
> > > Vendors will have to specify valid examples of what will be
> > > formatted within their anyxml.
> >
> > Specification by example is not very appealing IMO.   Ok, here's a
> > proposal for how to do this:

This is helpful.  I now understand what you are proposing.

> >   leaf filter-type {
> >     mandatory true;
> >     type identityref {
> >       base filter;
> >     }
> >   }
> >   choice filter-parameters {
> >     mandatory true;
> >     case subtree-parameters {
> >       when 'derived-from-or-self(../filter-type,
> >                                  "sn:subtree-filter")';
> >       anydata subtree {
> >         description "<copy text from 5277>";
> >       }
> >     }
> >     case xpath-parameters {
> >       when 'derived-from-or-self(../filter-type,
> >                                  "sn:xpath-filter")';
> >       leaf xpath {
> >         type yang:xpath1.0;
> >         description
> >           "<explain the XPath context, copy text from 5277>";
> >       }
> >     }
> >   }
> >
> > Now, if a vendor/sdo wants to add a new filter type, it can be done
> > like this:
> >
> >   identity regexp-filter {
> >     base "sn:filter";
> >     description
> >       "...";
> >   }
> >   augment "/sn:filters/sn:filter/sn:filter-parameters" {
> >     when 'derived-from-or-self(../filter-type,
> >                                "rx:xpath-filter")';
> 
> Here there should be a case:
> 
>   case regexp-parameters {
> 
> >     leaf regexp-dialect {
> >       type enumeration {
> >         enum "xsd";
> >         enum "posix";
> >         ...
> >       }
> >     }
> >     leaf regexp-expression {
> >       type string;
> >     }
> 
>   }

I like this augmentation structure.  With this, it is possible for vendor specific augmented objects to be added the model, versus parameters being embedded in the anydata.  Augmentations like this can be done with (b) too should people agree on filter parameters needing to be exposed.  Hopefully type of augmentation this can hold us until the time someone picks up filters holistically.

Eric  

> >   }
> >
> 
> 
> /martin
> 
> 
> 
> >
> > Once we have this, we can simplify by removing the identity; it isn't
> > really necessary.  (IIRC this was suggested by Juergen earlier in this
> > thread.)
> >
> >
> >
> > /martin
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> >