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

Rohit R Ranade <rohitrranade@huawei.com> Fri, 01 June 2018 09:10 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 DB53F1271DF for <netconf@ietfa.amsl.com>; Fri, 1 Jun 2018 02:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 dSKYnewZxXJU for <netconf@ietfa.amsl.com>; Fri, 1 Jun 2018 02:10:50 -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 9401F127137 for <netconf@ietf.org>; Fri, 1 Jun 2018 02:10:50 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AC64A54B43112 for <netconf@ietf.org>; Fri, 1 Jun 2018 10:10:46 +0100 (IST)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 1 Jun 2018 10:10:47 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0382.000; Fri, 1 Jun 2018 17:10:34 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Editorial change-2 for draft-ietf-netconf-nmda-netconf
Thread-Index: AdP5cHGIUfFqVxlzSpC0uX7jp7wZ7g==
Date: Fri, 01 Jun 2018 09:10:34 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.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_991B70D8B4112A4699D5C00DDBBF878A6BBB4569dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/qiprYDG37mvA12mcKR7Q1KVvQJM>
Subject: [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 09:10:53 -0000

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