Re: [netconf] get-data origin filters

Andy Bierman <andy@yumaworks.com> Sun, 06 October 2019 16:18 UTC

Return-Path: <andy@yumaworks.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 783B412011E for <netconf@ietfa.amsl.com>; Sun, 6 Oct 2019 09:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 sxlhmIK6i-G0 for <netconf@ietfa.amsl.com>; Sun, 6 Oct 2019 09:18:55 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF5C12004F for <netconf@ietf.org>; Sun, 6 Oct 2019 09:18:55 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id r134so7552450lff.12 for <netconf@ietf.org>; Sun, 06 Oct 2019 09:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kFxHVhR+srYH5Q4ZLklBN+HOI/4/DV2oqrv8CeENM4Y=; b=wh/rawFym5w2At2N5FWGRAt7JTWsFuyi41yA2ggHWXtCDKukExRIm8d6yREy82m1El b2Rw0KFJWBCAtWD2uslcGEkdHLNcj7hCgdIWi3zCX7MfipqWOm9CuigmLZBYRXBUI5rS LWFCvi7Uv6nEcRKCbwz24DYQ9mgVO6aR+jpOgGDL4GUoK63nHPkU7/keRfhjuFDpeZU+ 9JLE6jRlHNLgqjUVMMOYz214n75nRvkdEWDn1iAtESWrC72jl2fSpR7go2p8bdK0SdOl f6VU8IcJGqDVR2OTKKzoImfpTJFxbItw5Yvw7/8QylsmjfkqgHKHUI8LCF5woAsVK8G7 Cfyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kFxHVhR+srYH5Q4ZLklBN+HOI/4/DV2oqrv8CeENM4Y=; b=X86Vi6Je6cKvfn+Fm9k5BiUxPMczhUDjLkwsY2L5djoNuJEn6JU+/sLqrth11N6TAF f1jgLe03sDfaVQDUDVb/MH6gVtQNtD9PG4GOAix/Y4Bh3btHBc1XNKUUnMUCbym3OvH2 HHAgjynrrsQx8IUm0VdRXbKjd25v+fptmdQMUVx9ETIfqVnPB4qbNJu2J/Bo4cTr3F1S zhl+b8kqZDd8ZHMLWfVWoGx/CP3z9PFUsXYz24Qs/+ESx0r373yQHkBx7YUb325fX7AZ MIqKCIBbNyw27xOqt0pOawY0OSmY9jRkbGEIVsaJ56z+C5ONLw/i+puSUKaS5d1lcT2x RSSw==
X-Gm-Message-State: APjAAAWZVnhNT8UGR5vrf+3DZmi9WPY62hth0oYyMhN23GPEzNE/upDB h/7G/7XEjiC6Ef4Z/PTrycDwzycpDoNynovTQKkgnTV9Fug=
X-Google-Smtp-Source: APXvYqxw2agdCJjEI7RUEkCLt6ZNQhQOBOL3noh06FDe9dqWaxQh0L6Pshmz0/ysNn3TetELHpxZDaubkt9sqERCNFM=
X-Received: by 2002:ac2:5148:: with SMTP id q8mr13769078lfd.84.1570378733481; Sun, 06 Oct 2019 09:18:53 -0700 (PDT)
MIME-Version: 1.0
References: <CABCOCHSM0XO2tRDw44=jp3eaBxnhJciWOVvp8QJ+SgACjRZkEg@mail.gmail.com> <20191006.173256.1788347482117819951.mbj@tail-f.com>
In-Reply-To: <20191006.173256.1788347482117819951.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Sun, 06 Oct 2019 09:18:42 -0700
Message-ID: <CABCOCHRQDfprmHoMBBWK36DZH6-QQS1SkPu+V805XN3dBHW_FQ@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000928bf50594404aef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WBNDL0JaONhwofW4wIv5ZbQIrb4>
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 16:18:58 -0000

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.

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

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



/martin
>
>
Andy


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