Re: [netconf] get-data origin filters

Martin Bjorklund <mbj@tail-f.com> Sun, 06 October 2019 15:33 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 5AA45120044 for <netconf@ietfa.amsl.com>; Sun, 6 Oct 2019 08:33:01 -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 3VfuF9tiWK34 for <netconf@ietfa.amsl.com>; Sun, 6 Oct 2019 08:32:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B0572120043 for <netconf@ietf.org>; Sun, 6 Oct 2019 08:32:59 -0700 (PDT)
Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id C6FFF1AE018B; Sun, 6 Oct 2019 17:32:56 +0200 (CEST)
Date: Sun, 06 Oct 2019 17:32:56 +0200 (CEST)
Message-Id: <20191006.173256.1788347482117819951.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHSM0XO2tRDw44=jp3eaBxnhJciWOVvp8QJ+SgACjRZkEg@mail.gmail.com>
References: <CABCOCHSM0XO2tRDw44=jp3eaBxnhJciWOVvp8QJ+SgACjRZkEg@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/1WV8A9uylIN8FAq6iYkt3dQHHw4>
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: Sun, 06 Oct 2019 15:33:01 -0000

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>

> 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