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

Rohit R Ranade <rohitrranade@huawei.com> Tue, 19 June 2018 05:25 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 583E2130E39; Mon, 18 Jun 2018 22:25:54 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 MT_pj7WWlWFQ; Mon, 18 Jun 2018 22:25:51 -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 04CE7128CF3; Mon, 18 Jun 2018 22:25:51 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 76D8F8377CF34; Tue, 19 Jun 2018 06:25:47 +0100 (IST)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 19 Jun 2018 06:25:48 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0382.000; Tue, 19 Jun 2018 13:25:37 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: Kent Watsen <kwatsen@juniper.net>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <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: AdP5cHGIUfFqVxlzSpC0uX7jp7wZ7gAETTEAAIolOQAAAYmwAAGVpb+AAC3FYYAAEkICwP//ifkAgAiE3AD//wYVAA==
Date: Tue, 19 Jun 2018 05:25:37 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBC062A@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com> <a497b165-1f78-2d2f-9563-01fbb39619df@cisco.com> <20180604.121748.1873023460220711310.mbj@tail-f.com> <224028b2-59c5-6859-0e2a-331ed48121ec@cisco.com> <D42566D9-0C25-468E-B90F-B15589A7FB6D@gmail.com> <20180613102721.tnqufeommaojdwm2@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBBD928@dggeml510-mbx.china.huawei.com> <20180613120742.7xfgwy66jq6qxsmf@anna.jacobs.jacobs-university.de> <8AEB4F37-A148-428F-A5C0-1AB836F0733E@juniper.net>
In-Reply-To: <8AEB4F37-A148-428F-A5C0-1AB836F0733E@juniper.net>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/IesA58y60EgbUoIvvV-cxSnj89M>
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 19 Jun 2018 05:25:55 -0000

I agree with Juergen's comments. Only exception is that "intended" for " negated-origin-filter" will be qualified by the ietf-origin namespace.
Please find the updated 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"
               xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
       <datastore>ds:running</datastore>
       <subtree-filter>
         <bgp xmlns="http://example.com/ns/example"/>
      </subtree-filter>
       <negated-origin-filter>or:intended</negated-origin-filter>
       <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="http://example.com/ns/example" 
          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

-----Original Message-----
From: Kent Watsen [mailto:kwatsen@juniper.net] 
Sent: 19 June 2018 03:43
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>de>; Rohit R Ranade <rohitrranade@huawei.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>om>; Netconf <netconf@ietf.org>rg>; draft-ietf-netconf-nmda-netconf@ietf.org
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf

Let's conclude this thread and push an update (or updatres) to GitHub, so the update doesn't get lost as we head into the IESG LC.

Two items:
  - "origin-filter" parameter
  - <get-data> usage example 

Kent and Mahesh


===== original message =====

Yes, for bgp there is no namespace defined in the example in RFC 8342. Using ietf-netconf-nmda clearly is misleading, a fictional example namespace will be better.

I think the lexical representation of the value 'intended' requires to be namespace qualified, i.e. 'ds:intended'.

The with-origin is defined to be of type empty - there is no 'true'
value or something like that, its just <with-origin/>.

/js

On Wed, Jun 13, 2018 at 11:20:21AM +0000, Rohit R Ranade wrote:
> Hi Juergen,
> 
> Can you please identify the namespaces which are not OK so that we can fix them. 
> For want of a namespace for "bgp", I re-used the ietf-netconf-nmda namespace as it is just an example. We can use the "https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_ns_example&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=tm-DrFSVrRkMzAH-DiWECrNBbWhSmbKnBauKdzx3J-k&e=" namespace instead.
> 
> With Regards,
> Rohit R Ranade
> 
> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen 
> Schoenwaelder
> Sent: 13 June 2018 15:57
> To: Mahesh Jethanandani <mjethanandani@gmail.com>
> Cc: Netconf <netconf@ietf.org>rg>; 
> draft-ietf-netconf-nmda-netconf@ietf.org
> Subject: Re: [Netconf] Editorial change-2 for 
> draft-ietf-netconf-nmda-netconf
> 
> I am not sure an example is needed but if we include one, we need one which is correct. I think the namespaces are a bit messed up in Rohit's example.
> 
> /js
> 
> On Tue, Jun 12, 2018 at 08:36:47AM -0400, Mahesh Jethanandani wrote:
> > Have the authors agreed on the final set of edits for this document? How about the example that Rohit mentioned in the original e-mail?
> > 
> > > On Jun 4, 2018, at 7:01 AM, Robert Wilton <rwilton@cisco.com> wrote:
> > > 
> > > 
> > > 
> > > On 04/06/2018 11:17, Martin Bjorklund wrote:
> > >> Hi
> > >> 
> > >> Two comments inline.
> > >> 
> > >> Robert Wilton <rwilton@cisco.com> wrote:
> > >>> 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
> > >> I would prefer:
> > >> 
> > >>  selects nodes with origins equal to, or derived from, any of the 
> > >> given
> > >> 
> > >> 
> > >> IMO, the term "match" in the original text means "equal to or 
> > >> derived-from", as explained in the data model.
> > >> 
> > >> The term "match" is problematic unless it is explained, b/c some 
> > >> people will think it means "equal to".  (Noone will think that 
> > >> "matches the regular expression" means "equal to the regular 
> > >> expression" though...)
> > >> 
> > >> Conclusion: always avoid the term "match".
> > > OK.
> > > 
> > >> 
> > >>> +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).
> > >> Agree that "any" is correct.
> > >> 
> > >> But does it really change the semantics?  "all" sounds quite odd, 
> > >> but isn't the end result the same?
> > > I think that it is confusing, and probably depends on how you read it.
> > > 
> > > But, if you are OK with "any" then I think that reads better and is more intuitive.
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > 
> > >> 
> > >> 
> > >> /martin
> > >> 
> > >> 
> > >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.o
> > >>>> rg_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBX
> > >>>> eMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdc
> > >>>> Zo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_
> > >>>> -8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e=
> > > 
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-nd
> > > b3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Ehfh
> > > Srolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjt
> > > eIxUz56Qf08hiQBzQ3I&e=
> > 
> > Mahesh Jethanandani
> > mjethanandani@gmail.com
> > 
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=VZh0-GgZ6GpKnZhdi09mezzyPA62WEHUd5wPYbUVCI4&e=>
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXc
> WzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObT
> fkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBz
> Q3I&e=

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=VZh0-GgZ6GpKnZhdi09mezzyPA62WEHUd5wPYbUVCI4&e=>