Re: [netconf] get-data origin filters

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Sun, Oct 6, 2019 at 8:32 AM Martin Bjorklund <[e-mail]> wrote:
> 
> > Hi,
> >
> > Andy Bierman <[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?


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


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

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


/martin



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