Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf

Robert Wilton <rwilton@cisco.com> Fri, 01 June 2018 16:49 UTC

Return-Path: <rwilton@cisco.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 A490312D962; Fri, 1 Jun 2018 09:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cJzXkgZGnMbb; Fri, 1 Jun 2018 09:48:58 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C2712D961; Fri, 1 Jun 2018 09:48:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27897; q=dns/txt; s=iport; t=1527871737; x=1529081337; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=NWwBZ/95m90i1N7wEc2ODR2tpkwVV9FYcaqbHvkHXUs=; b=erJ2bbEWi5k6ZOjxY1ahl6qkEhfA2GQGUUz64AH3Xth+VyQzMpDoNAvL 3R1uwCV/MNbcIZZeT7ajH4cflDjRxKqJ1RRvGZ5U9QL2+4xQHrAT96CXv RRw518aoh07F+tnv4JN83f0Fgj885kuhoi0/WPn60OUuTemYoPS46c+N1 I=;
Received: from aer-core-3.cisco.com ([173.38.203.20]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 16:28:18 +0000
Received: from [10.63.23.83] (dhcp-ensft1-uk-vla370-10-63-23-83.cisco.com [10.63.23.83]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w51GMGKk017354; Fri, 1 Jun 2018 16:22:16 GMT
To: Rohit R Ranade <rohitrranade@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-nmda-netconf@ietf.org" <draft-ietf-netconf-nmda-netconf@ietf.org>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <a497b165-1f78-2d2f-9563-01fbb39619df@cisco.com>
Date: Fri, 1 Jun 2018 17:22:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------E80D606B457B2906A602BE2B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4L03y8iry6DGjKgz6_qroLZc-1c>
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing 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: Fri, 01 Jun 2018 16:49:01 -0000

Hi Rohit, authors,

I think that these are valid clarifications. I've reworded them 
slightly, and moved the ancestor node text to the YANG module instead.  
I also think that the ancestor node text generically covers the config 
filter clarification that you raised previously.

Hence, I propose the following diff to the NETCONF NMDA draft:

rwilton@rwilton-lnx:~/netconf-wg/netconf-nmda$ git diff --staged
diff --git a/ietf-netconf-nmda.yang b/ietf-netconf-nmda.yang
index f2929b9..72a674a 100644
--- a/ietf-netconf-nmda.yang
+++ b/ietf-netconf-nmda.yang
@@ -105,6 +105,9 @@ module ietf-netconf-nmda {
         by get-data must satisfy all filters, i.e., the filter
         criteria are logically ANDed.

+       Any ancestor nodes (including list keys) of nodes matched by
+       the filter are included in the response.
+
         The 'with-origin' parameter is only valid for an operational
         datastore. If 'with-origin' is used with an invalid datastore,
         then the server MUST return an <rpc-error> element with an
@@ -193,7 +196,7 @@ module ietf-netconf-nmda {
            description
              "Filter based on the 'origin' annotation.  A node matches
               the filter if its 'origin' annotation is not derived
-             from and not equal to all of the given filter values.";
+             from and not equal to any of the given filter values.";
          }
        }

diff --git a/nmda-netconf.org b/nmda-netconf.org
index e44e2c7..100e173 100644
--- a/nmda-netconf.org
+++ b/nmda-netconf.org
@@ -129,14 +129,17 @@ The "config-filter" parameter can be used to 
retrieve only "config
  true" or "config false" nodes.

  The "origin-filter" parameter, which can be present multiple times,
-selects nodes matching any of the given values. The
-"negated-origin-filter", which can be present multiple times, selects
-nodes that do not match all given values. The "origin-filter"
-and "negated-origin-filter" parameters cannot be used together.
+selects nodes with origins matching, or derived from, any of the given
+values. The "negated-origin-filter", which can be present multiple
+times, selects nodes with origins that do not match, and are not
+derived from, any of the given values. The "origin-filter" and
+"negated-origin-filter" parameters cannot be used together.

  The "max-depth" parameter can be used by the client to limit the
  number of sub-tree levels that are returned in the reply.

Note to the authors, for the negative-origin-filter, I've also changed 
"all" to "any" (which changes the semantics, but I think it was wrong 
before).

Similar updates will need to also be done to RESTCONF, but let's agree 
the NETCONF text first.

Thanks,
Rob


On 01/06/2018 10:10, Rohit R Ranade wrote:
>
> Hi All,
>
> Section 3.1.1
>
> OLD:
>
>    The "origin-filter" parameter, which can be present multiple times,
>
>    selects nodes matching any of the given values.  The
>
> "negated-origin-filter", which can be present multiple times, selects
>
>    nodes that do not match all given values.
>
> NEW:
>
> The "origin-filter" parameter, which can be present multiple times,
>
>    selects nodes which are derived from or matching any of the given 
> values.  The
>
> "negated-origin-filter", which can be present multiple times, selects
>
>    nodes which are not derived from and do not match all given values.
>
> When a data-node matching the filter is selected, the configuration 
> ancestors
>
> (if any) and list key leafs (if any), even if they do not match the 
> filter, are also returned.
>
> Consider two origins such as “learned” and “derived-from-learned”.
>
> “derived-from-learned” is derived from learned origin.
>
> Using the origin filters it is not possible to get nodes belonging to 
> “learned”
>
> only as the nodes of derived origin are automatically selected.
>
> Notes:
>
> The text in 3.1.1 did not include the “derived-from” logic for 
> selection , while in the data-model definition it was present.
>
>  We can also add clarification about the ancestor and key being 
> output, even if though they do match the filter, since the leaf
>
> matches the filter.
>
> Example : We can use the RFC 8342 Appendix C.2 BGP Example
>
>    <rpc message-id="101"
>
> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>
>      <get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
>
> xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
>
> <datastore>ds:running</datastore>
>
> <subtree-filter>
>
>          <bgp xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"/>
>
>       </subtree-filter>
>
> <negated-origin-filter>intended</negated-origin-filter>
>
> <with-origin>true</with-origin>
>
>      </get-data>
>
> </rpc>
>
>    <rpc-reply message-id="101"
>
> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>
>      <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
>
>       <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>
> or:origin="or:intended">
>
>        <peer>
>
> <name>2001:db8::2:3</name>
>
>          <local-as or:origin="or:default">64501</local-as>
>
>          <peer-as or:origin="or:default">64502</peer-as>
>
>          <local-port or:origin="or:system">60794</local-port>
>
>          <remote-port or:origin="or:default">179</remote-port>
>
> <state>established</state>
>
>        </peer>
>
>       </bgp>
>
>      </data>
>
>    </rpc-reply>
>
> With Regards,
>
> Rohit R Ranade
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf