Re: [netmod] [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 02 May 2018 12:55 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72CF126FDC; Wed, 2 May 2018 05:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XIPrKcBl3nlu; Wed, 2 May 2018 05:54:57 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727EA126D05; Wed, 2 May 2018 05:54:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 44C4D3B; Wed, 2 May 2018 14:54:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Z3rgu1lOYsfx; Wed, 2 May 2018 14:54:55 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 2 May 2018 14:54:56 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E961C20035; Wed, 2 May 2018 14:54:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fQ3EChRhp1SH; Wed, 2 May 2018 14:54:55 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38FE420031; Wed, 2 May 2018 14:54:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 53C3D42CA199; Wed, 2 May 2018 14:54:54 +0200 (CEST)
Date: Wed, 02 May 2018 14:54:53 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Rohit R Ranade <rohitrranade@huawei.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20180502125453.3fi63v2dw5tffcnd@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Rohit R Ranade <rohitrranade@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
References: <991B70D8B4112A4699D5C00DDBBF878A6B1E92F6@DGGEMA502-MBX.china.huawei.com> <20180425104222.2asz5wiuierdumr4@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B1F5AD1@DGGEMA502-MBS.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B1F5AD1@DGGEMA502-MBS.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3IFr_O7VnMwk6OZO2K_D4GjGIKk>
Subject: Re: [netmod] [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2018 12:55:01 -0000

On Wed, May 02, 2018 at 11:28:42AM +0000, Rohit R Ranade wrote:
> Hi Juergen,
> 
> Some thoughts in-lined.
> 
> With Regards,
> Rohit R Ranade
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: 25 April 2018 16:12
> To: Rohit R Ranade <rohitrranade@huawei.com>
> Cc: netconf@ietf.org; netmod@ietf.org
> Subject: Re: [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05
> 
> On Wed, Apr 25, 2018 at 04:22:24AM +0000, Rohit R Ranade wrote:
> > Hi All,
> > 
> > I plan to implement this draft and hence had some implementation related clarifications.
> > 
> > 
> > 1.       I feel that there should be more text added about "origin" filtering mechanism. I am not clear about some aspects of origin filtering.
> > 
> > RFC 8342 : NMDA RFC provides the below example
> > 
> > <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> >                  or:origin="or:intended">
> >        <interface>
> >          <name>lo0</name>
> >          <description>loopback</description>
> >          <ip-address or:origin="or:system">127.0.0.1</ip-address>
> >          <ip-address>::1</ip-address>
> >        </interface>
> >      </interfaces>
> > If user provides <origin-filter> as "system" ONLY, then he will NOT get this record in output. Because the keys have originated from "intended" . Right ?
> > So, If user wants to get the system originated data, he MUST give all the origins in the <origin-filter> where the keys of the system data have originated from. Can you please confirm whether this is OK.
> 
> I would expect that <origin-filter>or:system</origin-filter> would select the ip-address tagged with or:origin="or:system" and that the system would return any necessary container or list elements and the necessary key elements (since otherwise the value returned is just useless). So the result would be:
> 
>       <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>                   or:origin="or:intended">
>         <interface>
>           <name>lo0</name>
>           <ip-address or:origin="or:system">127.0.0.1</ip-address>
>         </interface>
>       </interfaces>
> 
> [Rohit R Ranade] While this looks OK for the origin filter, for the negated-origin-filter, for the same example given above, if <negated-origin-filter> or:intended<negated-origin-filter> is given, then it will give the "system" related nodes even if it encountered the "intended" node first, which the user definitely dint want included in the output ? Can you please confirm whether this is OK.

I think the leafs matter. Origin values on container and list nodes
are used for compactness. I think I wrote this already.

>    Can you please clarify whether the negated filter has higher priority than the selected filter ?

There are no priorities.

> > Another example given in RFC 8342 is as below:
> >      <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> >                  or:origin="or:intended">
> >        <interface or:origin="or:system">
> >          <name>lo0</name>
> >          <ip-address>127.0.0.1</ip-address>
> >          <ip-address>::1</ip-address>
> >        </interface>
> >      </interfaces>
> > 
> > ?  Here keys are originated from "system", but it is under container of "intended". So if user gives "system" for "origin-filter", the output will still NOT have this instance output ?
> 
> We allow origin values on containers or lists in order to inherit them, i.e., to achieve a more compact encoding. Anyway, if a leaf node matches, then I think any encompassing containers and list should be included in the result so that the matching leaf can be reported. So you would return
> 
>       <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>                   or:origin="or:intended">
>         <interface or:origin="or:system">
>           <name>lo0</name>
>           <ip-address>127.0.0.1</ip-address>
>           <ip-address>::1</ip-address>
>         </interface>
>       </interfaces>
> 
> instead of not returning anything at all.
> 
> > ?  Also the container is not defined as "presence" in C.3.  Interface Example, but still it has origin whether that is Ok ?
> 
> Why not?
> [Rohit R Ranade] RFC 8342 Section 5.3.4
> " The origin applies to all configuration nodes except non-presence containers.  "
>

There are origin attributes that apply to the data node where the
attribute is present and there are origin attributes that exist in
order to inherit them to other data nodes. A node that is not carrying
a configuration value and is not a presence container may have an
origin attribute for inheritance purposes.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>