Re: [netconf] get-data origin filters

Martin Bjorklund <mbj@tail-f.com> Mon, 07 October 2019 07:43 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD66412002F for <netconf@ietfa.amsl.com>; Mon, 7 Oct 2019 00:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEV-Hv4RvDlv for <netconf@ietfa.amsl.com>; Mon, 7 Oct 2019 00:43:56 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00391120020 for <netconf@ietf.org>; Mon, 7 Oct 2019 00:43:55 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 9EBF31AE018A; Mon, 7 Oct 2019 09:43:53 +0200 (CEST)
Date: Mon, 07 Oct 2019 09:43:27 +0200 (CEST)
Message-Id: <20191007.094327.1923088106819713441.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHRQDfprmHoMBBWK36DZH6-QQS1SkPu+V805XN3dBHW_FQ@mail.gmail.com>
References: <CABCOCHSM0XO2tRDw44=jp3eaBxnhJciWOVvp8QJ+SgACjRZkEg@mail.gmail.com> <20191006.173256.1788347482117819951.mbj@tail-f.com> <CABCOCHRQDfprmHoMBBWK36DZH6-QQS1SkPu+V805XN3dBHW_FQ@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/nS0BYesA3qMbVmYuz0luhwvbTZY>
Subject: Re: [netconf] get-data origin filters
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2019 07:43:58 -0000

Andy Bierman <andy@yumaworks.com>; wrote:
> On Sun, Oct 6, 2019 at 8:32 AM Martin Bjorklund <mbj@tail-f.com>; wrote:
> 
> > Hi,
> >
> > Andy Bierman <andy@yumaworks.com>; 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
> >