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

[Martin Bjorklund <[e-mail]>]

Hi Eric,

See comments inline.

"Eric Voit (evoit)" <[e-mail]> wrote:
> 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

It would help if you could provide valid YANG snippets of these three
options.  I *think* I know what you mean with (a) and (b), but not
(c).

> If we ever use (a) in any form, there is value in a parent identity.

What does this mean?

> As the current working draft is based (b), I will pull it out.

Hmm, are you saying that you will _not_ use (b)?

> We can
> always re-add in parallel with (b) if someone expresses a business
> need.

What does this mean?


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

Hmmm.  I now realize that I probably do not understand what (a) and
(b) are.  I thought my proposal was (b)...

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

Can you explain what this last sentence means?

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

Can you explain the problem in more details?  There might be a
solution to this.


/martin


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