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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 25 April 2018 10: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 C705F12421A for <netmod@ietfa.amsl.com>; Wed, 25 Apr 2018 03:55:31 -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 n_qPd4q3v9_t for <netmod@ietfa.amsl.com>; Wed, 25 Apr 2018 03:55:30 -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 BB920120721 for <netmod@ietf.org>; Wed, 25 Apr 2018 03:55:29 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 85606755; Wed, 25 Apr 2018 12:55:28 +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 BQPYubN-DFiE; Wed, 25 Apr 2018 12:55:27 +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, 25 Apr 2018 12:55:28 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EB6820031; Wed, 25 Apr 2018 12:55:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WGngJ7iKlgsH; Wed, 25 Apr 2018 12:55:27 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE0CE20035; Wed, 25 Apr 2018 12:55:27 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CDB3242C1393; Wed, 25 Apr 2018 12:55:27 +0200 (CEST)
Date: Wed, 25 Apr 2018 12:55:27 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Rohit R Ranade <rohitrranade@huawei.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20180425105527.jud4k2vxnzl5j322@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Rohit R Ranade <rohitrranade@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <991B70D8B4112A4699D5C00DDBBF878A6B1E8D96@DGGEMA502-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B1E8D96@DGGEMA502-MBX.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/l3lBsMZd2Rk-x46tA8YQfrxqo90>
Subject: Re: [netmod] 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, 25 Apr 2018 10:55:32 -0000

On Tue, Apr 24, 2018 at 01:09:07PM +0000, Rohit R Ranade wrote:
> Hi All,
> 
> Please find some comments for the draft.
> 
> 
> 1.       If "config-filter" leaf is not given for <get-data> whether we can add explicit text that both config=true and config=false nodes will be selected.

Well, if there is no filter, you do not filter. Is this not obvious?
 
> 2.       In the YANG module description for "config-filter" , also it is not clear about what happens if the leaf is not given in filter. I feel better we keep the style like RESTCONF RFC 8040 Section 4.8.1 , with "content" having  config/nonconfig/all

Why? Even in RESTCONF the content query parameter can be absent.

   If this query parameter is not present, the default value is "all".
 
> 3.       Regarding the "max-depth" parameter, I feel we should take the text about how "depth" is calculated for each node from RESTCONF RFC from Section 4.8.2 and add it to this draft. What will be depth of parent keys which are auto-selected when selecting on child nodes. Maybe some example regarding using of "max-depth" will be helpful.

I do not think the RESTCONF text talks about depths of parent keys which are
auto-selected. Here is what the I-D says:

             "For each node selected by the filter, this parameter
              selects how many conceptual sub-tree levels should be
              returned in the reply.  If the depth is 1, the reply
              includes just the selected nodes but no children.  If the
              depth is 'unbounded', all descendant nodes are included.";

What exactly is missing?
 
> 4.       For the <get-data> filter mechanism, since there are 4 filters (filter-spec and config-filter and max-depth and with-defaults), whether we can mention that all these filters are AND'ed. Also whether there is a suggested order to apply filter ? I think "max-depth" filter has to be applied last. Others maybe any order is OK.

Yes, I think the idea is that all filters apply. Do you have a
concrete proposal?

> 5.       negated-origin-filter : Regarding this I feel we can add a sentence as to when user should use "negated-origin-filter" , as "origin-filter" also can be used for this purpose.

Well, the set of origin values is not necessarily static. There are a
bunch of concrete values defined in RFC 8342 but technically origin
values are identities and thus extensible. Hence, if you want every
config true node which is not origin intended, then you better use
negated-origin-filter since trying list all origin-filter values is at
least fragile. Bottom line: if I want 'all except some', I use
"negated-origin-filter" and if I want 'all where' I use
"origin-filter".

/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/>