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

[Martin Bjorklund <[e-mail]>]

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.
> 
> 
> > 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?
> 
> > 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_engines
> > 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:
> 
> 
>   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;
>     }

  }

>   }
> 


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