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

Rohit R Ranade <rohitrranade@huawei.com> Mon, 04 June 2018 09:16 UTC

Return-Path: <rohitrranade@huawei.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 BAD5A124D37; Mon, 4 Jun 2018 02:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 KtPYK1zqqisy; Mon, 4 Jun 2018 02:16:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D12124C27; Mon, 4 Jun 2018 02:16:14 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 348EE32B98915; Mon, 4 Jun 2018 10:16:10 +0100 (IST)
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 4 Jun 2018 10:16:11 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0382.000; Mon, 4 Jun 2018 17:16:03 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: Robert Wilton <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-nmda-netconf@ietf.org" <draft-ietf-netconf-nmda-netconf@ietf.org>
Thread-Topic: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
Thread-Index: AdP5cHGIUfFqVxlzSpC0uX7jp7wZ7gAETTEAAJiSBvA=
Date: Mon, 4 Jun 2018 09:16:03 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB864E@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com> <a497b165-1f78-2d2f-9563-01fbb39619df@cisco.com>
In-Reply-To: <a497b165-1f78-2d2f-9563-01fbb39619df@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBB864Edggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/RorVpB6rbumB4krFdl7TjSKrYyA>
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: Mon, 04 Jun 2018 09:16:18 -0000

Hi Rob,

I am OK with the changes.
To enhance the understandability of the readers, please check if we can add an example in the draft for using the new filters, similar to the one I had given in my previous mail.

With Regards,
Rohit R Ranade

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 01 June 2018 21:52
To: Rohit R Ranade <rohitrranade@huawei.com>om>; netconf@ietf.org; draft-ietf-netconf-nmda-netconf@ietf.org
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf


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<mailto:Netconf@ietf.org>

https://www.ietf.org/mailman/listinfo/netconf