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
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 > >
- [netconf] get-data origin filters Andy Bierman
- Re: [netconf] get-data origin filters Martin Bjorklund
- Re: [netconf] get-data origin filters Andy Bierman
- Re: [netconf] get-data origin filters Martin Bjorklund
- Re: [netconf] get-data origin filters Andy Bierman
- Re: [netconf] get-data origin filters Rob Wilton (rwilton)
- Re: [netconf] get-data origin filters Andy Bierman
- Re: [netconf] get-data origin filters Rob Wilton (rwilton)
- Re: [netconf] get-data origin filters Andy Bierman
- Re: [netconf] get-data origin filters Martin Bjorklund
- Re: [netconf] get-data origin filters Andy Bierman
- Re: [netconf] get-data origin filters Martin Bjorklund