Re: [netconf] get-data origin filters

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Andy,

Don’t all the filters effectively work this way?

They select a subset of the nodes to include in the response, and must also include all ancestor nodes and required list keys to the selected nodes, regardless of whether those ancestor/key nodes were also selected by the query.

E.g. a “config false” filter will still return “config true” nodes if they are ancestors or list keys to a descendant config false node.  The same logic applies for xpath and origin filters as well.

Thanks,
Rob


From: netconf <[e-mail]> On Behalf Of Andy Bierman
Sent: 07 October 2019 15:12
To: Martin Bjorklund <[e-mail]>
Cc: Netconf <[e-mail]>
Subject: Re: [netconf] get-data origin filters



On Mon, Oct 7, 2019 at 12:43 AM Martin Bjorklund <[e-mail]<mailto:[e-mail]>> wrote:
Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:
> On Sun, Oct 6, 2019 at 8:32 AM Martin Bjorklund <[e-mail]<mailto:[e-mail]>> wrote:
>
> > Hi,
> >
> > Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:
> > > Hi,
> > >
> > > I am trying to figure out how to use the origin-filter and
> > > negated-origin-filter
> > > in the <get-data> operation in RFC 8526.
> > >
> > >
> > >           leaf-list origin-filter {
> > >              type or:origin-ref;
> > >              description
> > >                "Filter based on the 'origin' annotation.  A
> > >                 configuration node matches the filter if its 'origin'
> > >                 annotation is derived from or equal to any of the given
> > >                 filter values.";
> > >            }
> > >
> > >
> > > These filters seem kind of worthless if implemented according to the
> > text.
> > > Consider a simple example where there is 1 learned leaf within a list:
> > >
> > > module: address
> > >   +--rw addresses
> > >      +--rw address* [last-name first-name]
> > >         +--rw last-name     string
> > >         +--rw first-name    string
> > >         +--rw street?       string
> > >         +--rw city?         string
> > >         +--rw zipcode?      string
> > >         +--rw phone* [phone-type]
> > >            +--rw phone-type      enumeration
> > >            +--rw phone-number    string
> > >
> > > Let's say the "zipcode" field is learned in <operational>
> > > (e.g. ZIP code lookup expands missing or 5 digit zipcode to full 9 digit
> > > zipcode).
> > > So /addresses and /addresses/address have origin "intended".
> > > Only the /addresses/address/zipcode leaf has origin "learned".
> > >
> > > So how does origin-filter=learned find all the learned leafs?
> >
> > Perhaps I don't understand your question; IMO you give the answer to
> > this question below:
> >
> > > What filters are required to return only the learned entries + ancestors
> > +
> > > ancestor-or-self keys?  Seems like this filter mechanism has to be used
> > > to retrieve the exact leaf that might be learned, and the client
> > > needs to know in advance all the possible nodes that might be learned.
> > >
> > > Want to be able to retrieve an ancestor that is intended and still find
> > the
> > > learned entries
> > >
> > >    get-data xpath-filter=/addresses/address origin-filtter=learned
> >
> > ... here.  So this request will return:
> >
> >    <addresses or:origin="or:intended">
> >      <address>
> >        <last-name>...</last-name>
> >        <first-name>...</first-name>
> >        <zipcode or:origin="or:learned">...</zipcode>
> >      </address>
> >      ...
> >    </addresses>
> >
> >
> I do not interpret the text the same way as you.

Does this mean that you think that the reply is different from what I
show above?  If so, what would it be, and why?




Explain how the list address node has origin "learned".

The filter is for /addresses/address and only origin=learned.
How does the list node have origin=learned?
It can only have 1 value.
It has child nodes with both intended and learned as origin.
I do no understand how the origin=learned matched this node.




>
>                      The content returned
>
>           by get-data must satisfy all filters, i.e., the filter
>           criteria are logically ANDed.
>
>
>           leaf-list origin-filter {
>              type or:origin-ref;
>              description
>                "Filter based on the 'origin' annotation.  A
>                 configuration node matches the filter if its 'origin'
>                 annotation is derived from or equal to any of the given
>                 filter values.";
>            }
>
>
>               Configuration nodes that do not have an
>               'origin' annotation are treated as if they have the
>               'origin' annotation 'or:unknown'.
>
>
>
> > The draft shows an example where both "intended" and "system" are given
> > > as filters.  This will work but will include all the "intended" leafs as
> > > well.
> > > What if a "learned" node is within a "system" node within an "intended"
> > > node?
> >
> > This works as well.  Note that the get-data description says:
> >
> >           Any ancestor nodes (including list keys) of nodes selected by
> >           the filters are included in the response.
> >
> >
> >
>
> The issue is how the /iaddresses and /addresses/address nodes match the
> origin "learned".

They don't, but they are included b/c of the quoted text above (i.e.:
      Any ancestor nodes (including list keys) of nodes selected by
      the filters are included in the response.)


No.

If the filter was for /addresses/address/zipcode then maybe that text applies.
It is still unclear that the XPath is fully processed and then the origin-filter is processed.
The RFC just says they are ANDed together.



> The leafs in list "address" are a mixture of "intended" and "learned"
> origin.
> The text clearly says that a node has a single origin property, coupled to
> the annotation.
>
> Issue 1: mixed origin descendant nodes
> So how does a search on /addresses/address match origin-filter=learned?
> I cannot find any text that says what the origin of a list or P-container
> is if it
> contains nodes of mixed origin.

See above.

No text above explains how the list origin is tagged if it has multiple types of child nodes.



> Issue 2: NP-containers
>
> Also from RFC 8342:
>
>    The origin applies to all configuration nodes except non-presence
>    containers.
>
>
> What if the top-level node is an NP-container in this case.
> I thought the top-level node MUST have an origin attribute.
>
> The text is not clear how NP-containers are handled.
> Do they have an origin attribute? If not then RFC 8526 says they have
> origin "unknown".
> Is the intent that NP-containers always pass the origin-filter tests (test
> skipped)?

No, since they don't have an origin value they will not be selected by
the filter.  But an NP-container will be included in the reply if it
is the ancestor of a node that is selected by the filter.

The RFC text does not really say that.
Since it is very difficult to know if a data node 5 layers deep is going to match,
implementing these filters according to this vague interpretation is unlikely.


/martin

Andy



>
>
>
> /martin
> >
> >
> Andy
>
>
> >
> > > Seems like the client needs to know a lot about the server implementation
> > > details
> > > in order to use the origin filters.
> > >
> > >
> > > Andy
> >