Re: [netconf] get-data origin filters

[Martin Bjorklund <[e-mail]>]

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>

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


/martin


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