Return-Path: 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 To: Robert Wilton , "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> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 09:16:18 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6BBB864Edggeml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ha= d 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 ; netconf@ietf.org; draft-ietf-= netconf-nmda-netconf@ietf.org Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netco= nf Hi Rohit, authors, I think that these are valid clarifications. I've reworded them slightly, a= nd moved the ancestor node text to the YANG module instead. I also think t= hat the ancestor node text generically covers the config filter clarificati= on 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 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 ancesto= rs (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 "lear= ned" 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, eve= n 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 ds:running intended true 2001:db8::2:3 64501 64502 60794 179 established With Regards, Rohit R Ranade _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_991B70D8B4112A4699D5C00DDBBF878A6BBB864Edggeml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob,=

&n= bsp;

I am OK= with the changes.

To enha= nce the understandability of the readers, please check if we can add an exa= mple in the draft for using the new filters, similar to the one I had given= in my previous mail.

&n= bsp;

With Re= gards,

Rohit R= Ranade

&n= bsp;

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

 

Hi Rohit, authors,

I think that these are valid clarifications. I've r= eworded 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-nmd= a$ 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 th= e 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 {
           descriptio= n
            = ; "Filter based on the 'origin' annotation.  A node matches<= br>             = ;  the filter if its 'origin' annotation is not derived
-           &nbs= p; 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 b= e used to retrieve only "config
 true" or "config false" nodes.
 
 The "origin-filter" parameter, which can be present mul= tiple 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 togeth= er.
+selects nodes with origins matching, or derived from, any of the g= iven
+values. The "negated-origin-filter", which can be presen= t multiple
+times, selects nodes with origins that do not match, and are not
+derived from, any of the given values. The "origin-filter&quo= t; and
+"negated-origin-filter" parameters cannot be used togeth= er.
 
 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 s= emantics, but I think it was wrong before).

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

Thanks,
Rob

 

On 01/06/2018 10:10, Rohit R Ra= nade wrote:

Hi All,

 

Section 3.1.1=

 

OLD:

   The "origin-filter&q= uot; parameter, which can be present multiple times,

   selects nodes matching an= y of the given values.  The

   "negated-origin-filt= er", 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 d= erived from or matching any of the given values.  The

   "negated-origin-filt= er", 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 an= cestors

(if any) and list key leafs (if any), even if they do not match the fi= lter, 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 inclu= de the “derived-from” logic for selection , while in the data-m= odel definition it was present.

 We can also add clarifica= tion about the ancestor and key being output, even if though they do match = the filter, since the leaf

matches the filter.<= /span>

 

Example : We can use the RFC 83= 42 Appendix C.2 BGP Example

 

   <rpc message-id=3D&quo= t;101"

      &n= bsp; xmlns=3D"urn:ietf:params:xml:= ns:netconf:base:1.0">

     <get-data = xmlns=3D"urn:ietf:params:xml= :ns:yang:ietf-netconf-nmda"=

      &n= bsp;        xmlns:ds=3D"urn:ietf:pa= rams:xml:ns:yang:ietf-datastores">

       &= lt;datastore>ds:running</datastore>

       &= lt;subtree-filter>

      &n= bsp;  <bgp xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"/>

      &l= t;/subtree-filter>

       &= lt;negated-origin-filter>intended</negated-origin-filter>

       &= lt;with-origin>true</with-origin>=

     </get-data= >

   </rpc>= ;

 

   <rpc-reply message-id= =3D"101"

      &n= bsp; xmlns=3D"urn:ietf:params:xml:= ns:netconf:base:1.0">

    = <data xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">

      <bgp= xmlns:or=3D"urn:ietf:params:xml:n= s:yang:ietf-origin"<= /p>

      &n= bsp;   or:origin=3D"or:intended">

       &= lt;peer>

      &n= bsp;  <name>2001:db8::2:3</name>

      &n= bsp;  <local-as or:origin=3D"or:default">64501</loc= al-as>

      &n= bsp;  <peer-as or:origin=3D"or:default">64502</peer= -as>

      &n= bsp;  <local-port or:origin=3D"or:system">60794</lo= cal-port>

      &n= bsp;  <remote-port or:origin=3D"or:default">179</re= mote-port>

      &n= bsp;  <state>established</state>

       &= lt;/peer>

    =  </bgp>

     </data>=

   </rpc-re= ply>

 

With Regards,=

Rohit R Ranade

 




_______________________________________________
Netconf mailing list
Netconf@ietf.=
org
https://www.ietf.org/mailman/listinfo/netconf

 

--_000_991B70D8B4112A4699D5C00DDBBF878A6BBB864Edggeml510mbxchi_--