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

[Martin Bjorklund <[e-mail]>]

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")';
    leaf regexp-dialect {
      type enumeration {
        enum "xsd";
        enum "posix";
        ...
      }
    }
    leaf regexp-expression {
      type string;
    }
  }


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